Dependency on Media_wysiwyg module

Are you using the Panopoly profile? Or just the Panopoly WYSIWYG module on a non-Panopoly site?

Panopoly uses a relatively new version of Media 2.x, which has moved all of it's WYSIWYG functionality into a media_wysiwyg module. If you're using the full Panopoly profile, it'll update Media for you as well!

You can see exactly which revision we're using in the panopoly_widgets.make in case you want to update it yourself:

http://drupalcode.org/project/panopoly_widgets.git/blob/refs/heads/7.x-1...

This was updated in this release in order to get passed a revision affected by a security PSA:

#2171121: Update Media to at least 7.x-2.0-alpha3+37-dev for PSA-2014-001

Or if you're on a non-Panopoly site, and you don't want to update Media yourself, you could probably just remove the dependency in the panopoly_wysiwyg file and it should continue to work fine. :-)

Actually, another thing came to mind: you could be using the full Panopoly profile, but updating the panopoly_* modules without updating the WHOLE profile.

See the instructions at the top of the release notes for how to update Panpoly (the same goes for any Drupal distribution, like Commerce, Open Atrium, etc):

Instructions on how to upgrade:

1. Download the latest packaged version of Panopoly from Drupal.org. This will include updated versions of all of Panopoly's bundled modules, themes, and libraries.
2. Upgrade your existing site to use the code you just downloaded. Check out these instructions for more information: http://drupal.org/node/1223018
3. Backup your database and run update.php *TWICE* on your site. This may perform several database updates for Panopoly and its bundled apps and modules.
4. Navigate to the admin screen for Features (admin/structure/features) and revert any overridden features (unless you have intentionally made overrides you want to keep).

Release notes: https://drupal.org/node/2248645

Anyway, I hope that helps!

Yeah, you shouldn't be updating the Panopoly modules manually, you'll be missing important module upgrades and patches, and it's not guaranteed to work.

Please follow the instructions I copy-and-pasted in #2!

hmmmmmm, ran into this same issue in a pantheon installation of Panopoly. Any potential issues with the proposed solution in comment #2 with regards to pantheon?

@break9: Did you update using the Pantheon one-click update? Because the media_wysiwyg module is *definitely* in the Pantheon version of Panopoly:

https://github.com/populist/panopoly-drops-7/tree/master/profiles/panopo...

If you're not using this and instead manually updating your Panopoly installation, you have to make sure that *all* the changes in Panopoly get added to your Git repo. So, after copying the new Panopoly files in, be sure to run git add profiles/panopoly before committing.

Hi.

I've been merrily updating with "drush up" for, well, forever, except now I am having these problems with a dependency on a non-existent media_wysiwyg module, and undefined indexes, in a Panopoly distribution install. And other problems such as missing image display styles.

Does using drush count as "manually updating"? How does the above advice relate to a drush update?

@wu-lee: Yes, "drush up" counts as updating manually. Basically, "drush up" goes through all the modules it finds on your site and downloads the latest released version (unpatched in anyway) from Drupal.org. However, in Panopoly (and all Drupal distributions) we frequently include development versions and patches to fix important bugs or compatibility issues. We also add or remove modules between releases or need to stay on an older version of a module (for example, there are bugs with jquery_update 2.4 in Panopoly, so we need 2.3).

If you're updating with "drush up", you're missing out on all the hard work we've done on patching, selecting particular versions and testing.

In fact, what's happening in this exact situation, is that we upgraded from a particular revision of Media 2.x-dev to a newer revision (but not the newest, because it has bugs) for a security issue: #2171121: Update Media to at least 7.x-2.0-alpha3+37-dev for PSA-2014-001

In that update, Media also moved it's WYSIWYG code into a new module called media_wysiwyg. By updating with "drush up", you aren't getting that update! So, you get the message about missing media_wysiwyg and you also don't get the fix for the security PSA. This time you noticed that you were missing something (because of the media_wysiwyg error), but you're probably missing lots of other cool things.

For example, we added image cropping in Panopoly 1.4 which required a new module (manualcrop) to be added, plus it needed a number of patches in order to work correctly with Panopoly. You might not notice that this feature is missing or broken, but because you updated with "drush up", it is.

So, like mentioned above, the recommended way to upgrade Panopoly (or any Drupal distribution, since these same issues affect them all) is download the whole release and treat it like a Drupal core upgrade.

I hope that helps clearify the situation!

Thanks. I seem to have landed myself in a pickle, since after following those instructions it's clear I have modules in sites/all/modules and libraries in sites/all/libraries which are there because of drush up and/or my own desperate attempts to get things to work sensibly. I've moved the obvious ones aside and cleared the cache, things sorta seem to work, but I can only hope and cross my fingers that there aren't hidden breakages in the database as a result.

The panopoly_quarter_image style seems to be missing still, and some of my views which use it have gone awry.

One commment about the upgrade instructions: these might be clearer if they stated whether I needed to use panopoly with or without core when upgrading. Seems like it needs core?

Anyway, I am now worried that if I see the usual Drupal warnings about out of date modules requiring an update, I will need to ignore them or risk breaking Panololy's carefully patched modules. What's the correct procedure there?

In fact, presumably any modules I install in addition to the base Panopoly modules may also cause conflicts, if they require a different version of a module which Panopoly bundles?

I have the same problem. My site was running Panopoly 1.2 with Drupal 7.26. I applied an upgrade of core to 7.28 on May 12th. Then 'Available Updates' reported there were new versions available for my Panopoly modules. So, to upgrade Panopoly without downgrading core, I replaced the whole of [root]/profiles/panopoly with the directory tree from Panopoly 1.5.

Reading @dsnopek in comment #8, does this mean I mustn't apply Drupal core upgrades to a Panopoly site? That doesn't seem right. Surely core takes priority.

@socialtechno: Replacing the /profiles/panopoly directory WILL actually work for Panopoly, because we don't patch Drupal core (at least currently). So, if 'media_wysiwyg' is missing, something must have gone wrong with your copying process. If you download a fresh copy of Panopoly 1.5, you'll see that the module is present in /profile/panopoly/modules/contrib/media/modules/media_wysiwyg.

However, copying the profiles directory WON'T work with all Drupal distributions (or maybe even Panopoly in the future)! For example, Open Atrium and Commerce Kickstart both patch core, so updating those this way could actually break them. Which is why the recommended instructions for upgrading Drupal distributions are the way they are. :-)

As far as core updates: we try to make releases as close to the release of security updates to core as possible. We're trying to get to point where we release on the same day as any security releases that affect Panopoly. Drupal 7.28 wasn't a security release, so we'll update to that when the next Panopoly is ready, but there is no rush. But the "best practice" is to wait for the next Drupal distribution release, unless you know enough about how the distribution was put together that you can do the update yourself (ie. applying all necessary the core patches).

@wu-lee: We're working on a way to hide the update messages for modules that are managed by Panopoly: #2128959: Replace default "update" module behavior with something that makes sense for distributions. This issue has shown that this is higher priority than I thought it was! Unless you know how your distribution is put together, you really should always download the version that includes core per the issues I described above for @socialtechno.

As far as fixing your specific upgrade issues: try clearing the cache with drush cc all a couple times (Drupal sometimes has trouble finding modules after moving them to a different directory) and then reverting all Features with drush fra -y. Hopefully, that'll bring the 'panopoly_image_quarter' style back!

Just adding my bit that I have several panopoly sites that I recently had to spend what I'll politely call "a nontrivial amount of time" because unfortunate upgrades took place. For my bit, having managed modules having their update messages suppressed would be a godsend. Thanks for the good explanation of what's going on.

@dsnopek Thank you for your advice. I'm going to restore the backup and run it again, for the sake of my education.

Hi, the image styles are back now thanks.

However I've still a persistent problem when inserting an image using the WYSIWYG interface. Selecting the image from the library, there is a follow on page in the pop-up dialog in which the image settings are edited. This displays an error at the top of the dialog, which is apparently due to a custom date field associated with the image file type, because it goes away if I remove the field.

Warning: implode(): Invalid arguments passed in date_limit_format() (line 2132 of profiles/panopoly/modules/contrib/date/date_api/date_api.module).

Inspecting the stack trace, it seems to be coming from the panopoly-supplied date module, in date_limit_format(), called at line 327 of date_elements.inc, where the second argument is $field['settings']['granularity'] and this appears to be null. Looking further up the stack I see the field has no settings attribute, no attributes at all in fact.

I also see warnings in the Drupal log report, simply "Theme hook not found.", related to the date field in question.

I'm a bit stuck on this at the moment. Do you have any intuition what might be causing this?

@dsnopek
Hi!

I see the instructions you posted for upgrading a distribution. Is there a way to do this with drush? I found this on the Commerce Kickstart website about upgrading the Kickstart distribution. http://www.drupalcommerce.org/commerce-kickstart-2/install

$ drush dl commerce_kickstart
$ drush updatedb -y
$

I am guessing the same will work for upgrading the Panopoly distribution too. Is this correct?

Thanks for your time and help!

Frederick

@frederickjh: Yes, that will work with Panopoly as well. Just be sure that you're using a recent version of Drush and that you are in your Drupal directory when you run those commands.

We also now have more detailed updating document for Panopoly:

https://www.drupal.org/node/2272177

I hope that helps!