I've created a new tracking bug for anyone that wants to help:
http://tracker.moodle.org/browse/MDL-36920
David Scotson
Повідомлення, що надісла(ла)в David Scotson
I think it's worth having a go to get it working completely again, I'd appreciate any further help (that unit test thing has already save me a bunch of time). At the very least we can document what doesn't work with tests in case future versions of SQLite can fix those issues, as I think your work shows that many of them have fixed themselves just by waiting a while and upgrading PHP and the version of SQLite used.
I also think it might be an idea to convert all the Moodle database connections to use PDO rather than the native interfaces. One of the bugs I've hit is because the PDO driver has different behavior from the MySQLi one (returning an empty array for no results versus considering that an error and returning a boolean false). It's possible there's other such differences/bugs between the various native drivers. It seems sensible to converge on PDO if Moodle plans on supporting the variety of DBs that it does, though I admit I don't know what other considerations might make that a bad idea.
One strategy for getting SQLite working properly might be to write a PDO interface for Postgres or MySQL in parallel to figure out what's a bug in the PDO layer versus what isn't supported by SQLite.
Currently most of the database unit tests seem be passing, though there's one in the DML and one in DDL that seem to bring PHPUnit to a complete halt, some kind of infinite loop or so. Just need to figure out which of the tests that is and see how far we can take it.
I also think it might be an idea to convert all the Moodle database connections to use PDO rather than the native interfaces. One of the bugs I've hit is because the PDO driver has different behavior from the MySQLi one (returning an empty array for no results versus considering that an error and returning a boolean false). It's possible there's other such differences/bugs between the various native drivers. It seems sensible to converge on PDO if Moodle plans on supporting the variety of DBs that it does, though I admit I don't know what other considerations might make that a bad idea.
One strategy for getting SQLite working properly might be to write a PDO interface for Postgres or MySQL in parallel to figure out what's a bug in the PDO layer versus what isn't supported by SQLite.
Currently most of the database unit tests seem be passing, though there's one in the DML and one in DDL that seem to bring PHPUnit to a complete halt, some kind of infinite loop or so. Just need to figure out which of the tests that is and see how far we can take it.
Does this mean the java written test are officially deprecated, and the way forward is Behat and Mink?
I have to say I much prefer the Behat and Mink APIs so very am happy if they're the standard solution.
I had thought about rewriting the existing Java Selenium tests in Behat just to learn more about Behat (and to help test some renderers I was writing). Is there an official repository of tests yet that I could build on and contribute to (even if it's still in an alpha state), most of the documentation suggests that it's not quite got started yet but I'm happy to work on something half-finished if it's the way forward.
I have to say I much prefer the Behat and Mink APIs so very am happy if they're the standard solution.
I had thought about rewriting the existing Java Selenium tests in Behat just to learn more about Behat (and to help test some renderers I was writing). Is there an official repository of tests yet that I could build on and contribute to (even if it's still in an alpha state), most of the documentation suggests that it's not quite got started yet but I'm happy to work on something half-finished if it's the way forward.
A few quick notes,
I asked about the span.maincontent before, I believe it's used for a skiplink, but I think it could be replaced with a link to the maincontent area. See this bug for more:
http://tracker.moodle.org/browse/MDL-34723
Regarding the idea of using Bootstrap classes and Moodl classnames at the same time. It's a good idea, but note that there are some classnames which are used in both for different purposes. I've been documenting them here:
https://github.com/ds125v/moodle-theme_bootstrap_renderers/blob/master/style/undo.css
Often the Moodle usage is inconsistent so I'd vote for solving the clashes by changing the Moodle classnames.
For tables I like the bootstrap idea of .table for tables that are used as tables (i.e. containing tabular data and that you can style with a standard stripey look) since both Moodle and content seem to use table (tag, I put it in pointy brackets and the rest of my comment got eaten) and even .generaltable for things that aren't tabular data.
I asked about the span.maincontent before, I believe it's used for a skiplink, but I think it could be replaced with a link to the maincontent area. See this bug for more:
http://tracker.moodle.org/browse/MDL-34723
Regarding the idea of using Bootstrap classes and Moodl classnames at the same time. It's a good idea, but note that there are some classnames which are used in both for different purposes. I've been documenting them here:
https://github.com/ds125v/moodle-theme_bootstrap_renderers/blob/master/style/undo.css
Often the Moodle usage is inconsistent so I'd vote for solving the clashes by changing the Moodle classnames.
For tables I like the bootstrap idea of .table for tables that are used as tables (i.e. containing tabular data and that you can style with a standard stripey look) since both Moodle and content seem to use table (tag, I put it in pointy brackets and the rest of my comment got eaten) and even .generaltable for things that aren't tabular data.
Since the topic is standardization I'd suggest the easiest and best way to achieve that aim is to have to have the code put into re-usable functions e.g. assuming that your code example is going to be used in more than one place then first decide what standard "semantic" function it provides, let's say it's a footer link :
function footer_link($href, $text)
It's a lot easier to get consistency this way and has the added benefit that those re-usable units can be "themed" independently. This is currently hit-or-miss with some core functions "renderized" and others not, and sometimes there's not enough semantic info provided to decide how to render them (e.g. if I'd used generalbox_link here, then you'd not know much about what the link was for, just that someone had decided that visually it should go in a box, similar to Tim's point about ,border-round).