Hi
I only managed to get to updating my farmos installs now, so I am a bit late to 3.3.3. As usual, it’s not smooth at all for me. I noticed some other issues on the forums, but they don’t seem to be related to this one.
I unpacked, overwrote the neccesary (except sites), drush’d, composer updated (twice) and did the update.php things, and I get a 500.
Cannot do “admin/config/development/performance” due to the 500.
Logs entry of note:
[09-Feb-2025 19:15:28 Africa/Johannesburg] PHP Fatal error: Cannot redeclare gin_theme_suggestions_table_alter() (previously declared in /home/farmos/public_html/web/themes/gin/includes/table.theme:11) in /home/farmos/public_html/web/themes/gin/includes/theme.theme on line 145
I hope that this is a simple issue and that I won’t need some rare potion. Thank you in advance to anyone with some ideas
Did you delete everything (except sites), and then replace it with the fresh code? Overwriting alone doesn’t guarantee that files that need to be removed are deleted.
I don’t know if Gin changed which file their gin_theme_suggestions_table_alter() function is in, but if they did, and they removed gin/includes/table.theme, but you didn’t, then that would explain your error.
No, always did a overwrite. Delete makes sense, but again, didn’t know. Suddenly something new. Drupal’s process of updating is far from friendly and welcoming. THanks Mike, appreciate. Will give that a try
@mstenta Thank you for the advice.
Deleting (well, renaming everything to _old) and bringing in the new package solved it. Apart from having to re-require all the modules/extensions, it solved the issue. Will have to add a note to the list of things needed to upgrade.
For what it’s worth, this “packaged release” approach to installing/updating farmOS is a legacy option we provide to try to make it easier for folks on shared hosting. Drupal has long moved away from this, in favor of using Composer commands directly.
We will most likely be moving to this as well in farmOS 4.x+, because of these exact issues.
In my experience, Drupal’s update process pre-dating composer-managed systems, was quite a bit nicer than what most other frameworks offered.
For anyone still relying on this, it does help to have a simple trick or two up your sleeve. I manage all my php projects with composer now, but something I used to do back in the days when I managed drupal deployments this way, was that I’d always keep my /sites dir outside of the drupal directory, and simply link it in with a symbolic link. When an update became available, I’d drop the latest release into a new directory, and symlink my /sites into that one, run necessary update scripts, test, and then configure the web server for that directory and cycle it. If any problems emerged, the previous version remained in tact and unchanged… dead simple to rollback to it, in a pinch.
This could be thought of as the poor man’s “blue-green” deployment strategy
I think Drupal’s maturation process away from the ^ above described ways, to becoming a composer-managed system was much more drawn out, perhaps more painful process than a lot of other php frameworks, but it has been mature for awhile now.
It’s generous of Mike and FarmOS to continue offering the packaged release, but the friction will continue to grow and so embracing composer-managed deployments (and ideally also your own version control) hopefully is on everyone’s radar.
