Friendica/upgrading

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search

About

This page is about upgrading Friendica instances.

Steps

The folder where you put Friendica – which should be the same as your public web folder (typically public_html), will be referred to as <fka-root>.

To determine what version you are currently running, look at the <fka-root>/VERSION file. Upgrading must be done in stages: 3.54, 2018-09, and finally 2019-09.

The configuration file is <fka-root>/.htconfig.php, although it is distributed without the dot prefix (just htconfig.php).

  1. Unzip or git clone the version of Friendica to which you are trying to upgrade.
  2. Rename the configuration file to .htconfig.php.
  3. Edit the configuration file to have the proper access parameters for your Friendica database.
  4. Open a terminal in <fka-root> and run:
    • bin/console dbstructure update (NOTE: this folder does not exist in 3.5.4; trying to find out what the equivalent is)

in progress

Documentation Whine

Database upgrade instructions are still difficult to find as of v2019-09:

  • Update instructions on the 2019-09 release page say "please first update your Friendica instance to [v2018-09]".
  • Update instructions on the 2018-09 release page say "First update to the 3.5.4 release", but do not link to instructions.
  • The 3.5.4 release page does not seem to have any update instructions.

Documentation for upgrading Friendica's code and database schema was minimal or at least difficult to find as of 3.5.2-dev. The following were applicable[1]:

  1. Friendica automatically detects database issues and, when they are encountered, attempts to run a database upgrade.
  2. Before starting, it automatically puts the site into maintenance mode.
  3. If the upgrade completes successfully, it presumably takes the site back out of maintenance mode.
  4. If the upgrade does not complete successfully, there are no notifications to this effect; you have to check the logfile for errors.
  5. The current schema – much like Hubzilla's – has many table rows which try to set a default value for a DATETIME column, which (as of MySQL v5.7.17) may be disallowed by the server configuration.[2]

This means that the automated upgrade may fail, and the SQL to create or modify tables will have to be tweaked and executed manually. (Details may change from version to version, but my notes are here.)

Old Notes

Notes I took during the last upgrade seem to indicate that there was a way to explicitly request a db upgrade in the "admin area", but I haven't been able to find the admin area yet in the current version (which isn't currently working; hopefully when I get it working, it will appear and I can update this section).

Previous notes said:

The update process does not always go smoothly. If you see a message like this in the admin db_updates area:

Executing update_1141 failed. Check system logs.

...then what you need to do is view the update.php file, manually execute the given SQL (adjusting permissions or whatever is necessary until it has executed), and then click the "DB updates" link again to get the list of failed updates (in this case, it should show 1141) and then click on the link which says "Mark success (if update was manually applied)".

Footnotes

  1. 2017-04-08 Friendica migration follow-up post
  2. ibid. If the MySQL server is in strict mode and NO_ZERO_DATE is enabled, default values for DATETIME columns must be between '1970-01-01 00:00:01' and '2038-01-19 03:14:07' inclusive. "DEFAULT '0001-01-01 00:00:00'" is therefore disallowed, as are the many '0000-00-00 00:00:00' column values. (Found via Stack Overflow.)