David Scotson

There's probably a bunch of ways to do it, but one way I'd imagine would be for anyone developing a plugin to clone the main Moodle on github and create a branch for each combination of Moodle version and plugin they support (e.g. plugin-x-2.2 and plugin-y-2.3) to which they would regularly pull the latest code for their their plugin and update to the latest Moodle on that branch and commit in order to run the full test suite via Travis.

You'd need to be doing something like this (installing the plugin into an actual Moodle) to do basic checks during development anyway. This just gives you a bit more structure for doing that and perhaps encourages you to check against multiple versions by making it a bit easier (by using git checkout to switch between branches).

This is what we've been doing since our plugins are mostly in-house and so live in a Moodle tree.

If you wanted to be fancy you could script it so that when you commit to just your plugin github then Travis goes off and downloads Moodle and then runs the tests. You could use env variables so that each commit gets run against multiple versions of Moodle too, in much the same way as the current .yaml downloads and installs PHPUnit and tests against combinations of PHP and DB.

Even with the change in place MySQL seems to be functioning. It might just be my imagination since this is a dev server but it seems slower. Maybe it's just slow compared with sqlite? Could those brackets really have a performance impact, and how would I got about measuring it if they do? I suppose I could just switch the change back and forth with MySQL and Postgres and see if there's any notable change, but that' doesn't seem very scientific.

There appears to be a in the Calendar Block and Upcoming Events block that blows up if it returns nothing from the database, since that get turned into a "false" which is later treated like an array. Yet other calls go through the same code and return nothing and function as expected (maybe they all check for false), and stranger still the same code works for MySQL (actually, that's not true, it's not the same code, it's just equivalent code, so I guess there's a difference somewhere that can be found and fixed). If you hide those two blocks though you appear to have a fully functioning Moodle site on sqlite.

I changed a couple of lines in accesslib and it seems to have fixed this error. Now pretty much everything seems to work, though I'm still not able to see the site homepage due to an error with the calendar block. But every admin link I tried worked and I was able to create a course and add some activities.

https://github.com/ds125v/gumoodle/commit/d5aacf71656f7edaa0ee4012aff6d2a924e2d1a9

I've not yet tested to see whether the fix is sqlite specific and breaks other databases.

The unit tests don't seem to work at all with an sqlite database but I think that's perhaps an error with how they are being set up. The test database doesn't seem to get created at all during the unit test setup script (which unsurprisingly causes a bunch of failures), yet the same DB creation steps seems to happen with no problems during installation.

Running just the DML unit tests gets errors about "General error: 10 disk I/O error" which I think means it can't find and/or access the database file.

My best guess is that the syntax for union with order by is very slightly wrong at the outer brackets for grouping what you want to "order by", but i'm not sure yet where to fix it:

After substituting in the relevant values manually this works with what looks like correct results if I give it to the DB directly:

SELECT * FROM
(
SELECT ctx.path, rc.roleid, rc.capability, rc.permission
FROM role_capabilities rc
JOIN context ctx  ON (ctx.id = rc.contextid)
JOIN context pctx ON (pctx.id = 1 AND (ctx.id = pctx.id OR ctx.path LIKE pctx.path||'/%' OR pctx.path LIKE ctx.path||'/%'))
LEFT JOIN block_instances bi ON (ctx.contextlevel = 80 AND bi.id = ctx.instanceid)
LEFT JOIN context bpctx ON (bpctx.id = bi.parentcontextid) WHERE rc.roleid = 7  AND (ctx.contextlevel <= 50 OR bpctx.contextlevel < 50)

UNION

SELECT ctx.path, rc.roleid, rc.capability, rc.permission
FROM role_capabilities rc
JOIN context ctx ON (ctx.id = rc.contextid)
JOIN context pctx ON (pctx.id = 2 AND (ctx.id = pctx.id OR ctx.path LIKE pctx.path||'/%' OR pctx.path LIKE ctx.path||'/%'))
LEFT JOIN block_instances bi ON (ctx.contextlevel = 80 AND bi.id = ctx.instanceid)
LEFT JOIN context bpctx ON (bpctx.id = bi.parentcontextid) WHERE rc.roleid = 8 AND (ctx.contextlevel <= 50 OR bpctx.contextlevel < 50)
)
ORDER BY capability;

but this is what is being produced at the moment:

(
SELECT ctx.path, rc.roleid, rc.capability, rc.permission
FROM role_capabilities rc
JOIN context ctx ON (ctx.id = rc.contextid)
JOIN context pctx ON (pctx.id = 1 AND (ctx.id = pctx.id OR ctx.path LIKE pctx.path||'/%' OR pctx.path LIKE ctx.path||'/%'))
LEFT JOIN block_instances bi ON (ctx.contextlevel = 80 AND bi.id = ctx.instanceid)
LEFT JOIN context bpctx ON (bpctx.id = bi.parentcontextid) WHERE rc.roleid = 7 AND (ctx.contextlevel <= 50 OR bpctx.contextlevel < 50)

) UNION (

SELECT ctx.path, rc.roleid, rc.capability, rc.permission 
FROM role_capabilities rc
JOIN context ctx ON (ctx.id = rc.contextid) 
JOIN context pctx ON (pctx.id = 2 AND (ctx.id = pctx.id OR ctx.path LIKE pctx.path||'/%' OR pctx.path LIKE ctx.path||'/%')) 
LEFT JOIN block_instances bi ON (ctx.contextlevel = 80 AND bi.id = ctx.instanceid) 
LEFT JOIN context bpctx ON (bpctx.id = bi.parentcontextid) WHERE rc.roleid = 8 AND (ctx.contextlevel <= 50 OR bpctx.contextlevel < 50)
)
ORDER BY capability;

It seems pretty much totally broken at first, but it's actually not that bad.

For example, with a couple of minor tweaks it seems to get all the way through the install fine. It bombs out right at the end, but actually that appears to be when it's trying to display the calendar block on the first page, the actual install has worked fine. If you then go to the admin area of the site then I'd say that about half the links you click on work fine, though obviously that means half are broken with an not very helpful message.

With a bit more fiddling to actually get the error bubbled up to the surface and you get this quite scary looking thing back:

General error: 1 near "(": syntax error

(SELECT ctx.path, rc.roleid, rc.capability, rc.permission FROM role_capabilities rc JOIN context ctx ON (ctx.id = rc.contextid) JOIN context pctx ON (pctx.id = :c1_7 AND (ctx.id = pctx.id OR ctx.path LIKE pctx.path||'/%' OR pctx.path LIKE ctx.path||'/%')) LEFT JOIN block_instances bi ON (ctx.contextlevel = 80 AND bi.id = ctx.instanceid) LEFT JOIN context bpctx ON (bpctx.id = bi.parentcontextid) WHERE rc.roleid = :r1 AND (ctx.contextlevel <= 50 OR bpctx.contextlevel < 50) ) UNION (SELECT ctx.path, rc.roleid, rc.capability, rc.permission FROM role_capabilities rc JOIN context ctx ON (ctx.id = rc.contextid) JOIN context pctx ON (pctx.id = :c2_8 AND (ctx.id = pctx.id OR ctx.path LIKE pctx.path||'/%' OR pctx.path LIKE ctx.path||'/%')) LEFT JOIN block_instances bi ON (ctx.contextlevel = 80 AND bi.id = ctx.instanceid) LEFT JOIN context bpctx ON (bpctx.id = bi.parentcontextid) WHERE rc.roleid = :r2 AND (ctx.contextlevel <= 50 OR bpctx.contextlevel < 50) )ORDER BY capability

So it would appear that while you can do stuff (like install Moodle) as an Admin, it's breaking when anything needs to check your roles, but (crucially) it seems to be the exact same error every time. So although it looks a bit scary it might just need that one fix to have it up and running in general.

I'll try breaking that down and feeding it directly to Sqlite to see what it's not liking. My first guess would be those :r1 bits.