21 May 2026, 23:07

We are currently doing some test upgrades of Mahara from 25.04 to 26.04, the upgrades are taking a long time to complete the upgrade of the blocktype.internal/textbox from version 2.0.1 to version 2.0.2, in the web upgrade page. I did a previous test upgrade using the command line tool and it also took a long time on this plugin type, approximately 3 hours.

Is this to be expected, I assume it is probably having to change something for each instance of that block and it is a very commonly used block on our site. If it is expected that is fine we just need to adjust our upgrade timings to accommodate.

Thanks

James

22 May 2026, 2:22

I ran a similar test the other day, and though my test db is small it still took 16mins, which is a forewarning of things.

It is, as you say, related to the textblock, I think specifically this change: https://git.mahara.org/catalyst/mahara/-/work_items/738

One query in the upgrade script returned 82 items in my dev, but 286629 in prod

SELECT id, configdata
FROM block_instance
WHERE blocktype = 'textbox'
AND configdata LIKE '%\"artefactid\";%';

It'd be interesting to see the timings when we upgrade. I will probably set aside a day for downtime.

22 May 2026, 11:51

The upgrade to 26.04 includes an amalgamation of the 'text' block type and 'textbox' block type as they were mainly doing the same thing into one 'textbox' block and deprecate the 'text' block type.

Because of this an upgrade step need to turn all the 'text' block types into 'textbox' block types and generate their underlying artefact as well as adjust all the 'textbox' blocks.

This will cause upgrade slowness on site that have many 'text' / 'textbox' blocks.

Cheers

Robert

22 May 2026, 20:47

@Robert Lyon,

When we start to do this upgrade, do we risk running into time-outs? Does the upgrade script cycle through batches or just try to complete everything in one go?

We also could get into trouble here. Just trying to anticipate this.

22 May 2026, 21:57

@Richard van Iwaarden

I've run the upgrade twice on our test server. First time was using the command line script. That took 3 hours approximately but needed no additional input. I have since run it in the browser, the script timed out a few times but I was able to re start the script by adding ?rerun=1 as a query on the upgrade.php url. That did need me to check in on the site every so often as the script would time out.

Robert may be able to confirm if we would expect that re-running to work correctly.

I hope that helps.

James

22 May 2026, 22:03

I would always run an upgrade from the CLI. Also, I'd use something like tmux which will enable you to reattach a session if you lose connection.

23 May 2026, 1:39

I understand. But that does require you to have shell access. Not all hosted servers supply this. However, access to files is no problem. Until now we could run upgrades by uploading the files and starting the upgrade process from a browser.

25 May 2026, 10:59

Hi everyone,

There are a couple of places that can be tweaked to allow for a longer timeout duration if one needs this.

1. In https://git.mahara.org/catalyst/mahara/-/blob/main/htdocs/lib/upgrade.php?ref_type=heads#L1699 the function upgrade_loop_display one can se the $timelimit to higher that 30 secs. What this setting does is to give an addition 30 secs in the future for each loop of the upgrade. If however an instance of the lop takes longer than 30 secs by itself then the upgrade will time out.

2. In https://git.mahara.org/catalyst/mahara/-/blob/main/htdocs/artefact/internal/blocktype/textbox/db/upgrade.php?ref_type=heads#L115 adjust the $limit = 50; to a smaller number so that less is processed per loop. This might make the upgrade slower but should avoid timeouts better.

This will mean someone having access to the server will need to make the changes but as they are both adjusting  a number it should be in the realm of any sysadmin.

Cheers
Robert