Bug #4557

Missing plugins during application upgrade breaks AtoM

Added by Jesús García Crespo over 9 years ago. Updated over 7 years ago.

Status:VerifiedStart date:01/25/2013
Priority:HighDue date:09/12/2014
Assignee:Jesús García Crespo% Done:


Category:InstallationEstimated time:8.00 hours
Target version:Release 2.1.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:


Under the following scenario:

  1. Install the latest stable 1.x release
  2. Activate qtTrilliumPlugin as the preferred theme.
  3. Upgrade to 2.x

During the site upgrade, symfony tools:upgrade-sql will fail because when the Symfony stack is loading all the plugins (including those configured in the user database), it won't find qtTrilliumPlugin as it was removed from 2.x. symfony tools:atom-plugins won't be able to change the plugins configuration neither for the same reason. So the user needs to go to the database and remove the missing plugin manually. I need to revisit the plugins the user plugins code to find a solution.


#1 Updated by Jesús García Crespo almost 9 years ago

  • Category changed from 43 to Installation

#2 Updated by Mike Gale over 7 years ago

  • Status changed from New to Code Review

Hi, I've proposed a solution here: https://github.com/artefactual/atom/tree/dev/issue-4557-missing-plugins

I'm sure that maybe there are a few changes you might want to make Jesus, it isn't perfect, but it gets the job done! :)

#3 Updated by Jesús García Crespo over 7 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from Jesús García Crespo to Mike Gale

Looks great, MikeG. I'd like to suggest though that next time you assign a ticket to another dev for Code Review, please file a pull request and in the description field try if possible to add a short description of what's the solution suggested and link it from the Redmine ticket. Or just throw the details in the ticket, as you prefer.

One of the gotchas is that you are forcing the user to install php5-readline, but that's not currently in our installation docs neither in our deployment scripts, etc... so it may need a few updates here and there according to this change. Curiously, we merged a pull request the other day from a developer patching another symfony task where readline was being treated as a dependency, he made it optional. Maybe you could take a similar approach, although you may think it's just easier to introduce php5-readline. Not a big deal for me.

Other than that, great job! :)

#4 Updated by Jesús García Crespo over 7 years ago

By the way, this is weird but I think you could have more than one theme running at the same time. Well, it was possible but not sure if it's still possible these days. The current theme being used can be retrieved by getting a list of plugins from the corresponding setting_i18n row and exclude those that don't include the word "theming" in the $summary property... I know, not too elegant. See more here: https://github.com/artefactual/atom/blob/qa/2.1.x/plugins/sfPluginAdminPlugin/modules/sfPluginAdminPlugin/actions/themesAction.class.php#L60

It would be good to work on an approach that doesn't require a hardcoded list of plugins because there are cases where the user has its custom theme enabled in the database but it's not available during the upgrade - maybe because the theme needs code upgrades but they still want to run the upgrade-sql task.

#5 Updated by Mike Gale over 7 years ago

Okay, if that's how we test for the current theme then I wasn't missing anything. And so therein lies the problem--because we're dealing with themes that are no longer present under plugins/ during the upgrade, we can't read them in to test $summary to see if it contains the string "theme" in it. :( -- so that's why I've hard coded in Trillium and Allouette for removal. I have another idea though, see below:

Instead of separating the code for testing for old themes vs. removing non-theme plugins, make it all the same code. And do the following:

1. For each missing plugin (regardless if theme or not), prompt user yes/no if they want to remove the plugin (user can select "no" for a custom theme that isn't available at the moment, for instance).
2. After all missing plugins are dealt with, re-scan all the plugins in the settings
3. If none of the scanned plugins have "theme" in $summary, prompt the user yes/no if they want to set a new theme.

#6 Updated by Jesús García Crespo over 7 years ago

Sounds great, Mike!

#7 Updated by Jesús García Crespo over 7 years ago

  • Priority changed from Critical to High

This is a nice to have, but I'm moving this down to High.
It's not a critical, as long as we can describe a workaround in the upgrading instructions: disable custom plugins.
But I still think that we should include it in the release.

#8 Updated by Jesús García Crespo over 7 years ago

  • Due date set to 09/12/2014
  • Status changed from Feedback to In progress

#9 Updated by Jesús García Crespo over 7 years ago

If you are going to require the readline extension, please update the docs accordingly. There is a list of extensions in admin-manual/installation/requirements.rst, also a command line showing how to install all the extensions at once in admin-manual/installation/linux.rst. I think that the package is only available in 14.04, in 12.04 is included in php5-common but I'm not 100% sure, you may want to verify that too.

#10 Updated by Mike Gale over 7 years ago

  • Status changed from In progress to Code Review
  • Assignee changed from Mike Gale to Jesús García Crespo

#12 Updated by Jesús García Crespo over 7 years ago

  • Status changed from Code Review to Verified

Tested with three different 1.x data sets.

Also available in: Atom PDF