Typing this here in case anyone else bumps into the same problem. The cause was that updating Date chmodded its own directory tree 700 and the solution was chmodding it back to 755.
This raises one question: Is there a way to make sure the module updates itself with the correct chmods in the future? Having to SFTP each time the plugin is updated through Drupal's update panel seems the least optimal solution. This one's currently categorized as a bug report as it seems that using Drupal's built-in update shouldn't lead to this. In case the chmods cannot be prevented from failing, there could be a check that then informs the siteadmin if that is indeed the problem. My perception is that some modules have automatically set their permissions differently on install/update so this might be a module issue instead of core.
The date popup symptoms (skipping the details of others such as Date All Day not working at all etc):
After upgrading to Date 7.x-2.0-rc1 from 7.x-2.0-alpha5, the popup functionality stops working. Rerolled the site and database and tested immediately before and after updating the module - before works, after doesn't. Neither the date popup or the WVega timepicker function. Also the formatting of the area in the Create Node page goes awry: The dates are no more enclosed in boxes and there's a line break after each input field.
Screenshots attached. Nothing else changed in between the two first except updating Date to 7.x-2.0-rc1 from 7.x-2.0-alpha5 and between the two last only chmod -R 755 sites/all/modules/date.
| Comment | File | Size | Author |
|---|---|---|---|
| datepopupbugafterupgradingto7.x-2.0-rc1andchmod755.png | 3.75 KB | Daedalon | |
| datepopupbugafterupgradingto7.x-2.0-rc1.png | 2.41 KB | Daedalon | |
| datepopupbugpreupgradingto7.x-2.0-rc1.png | 3.98 KB | Daedalon |
Comments
Comment #1
karens commentedNothing was changed to file permissions in this module. All files have exactly the same permissions as every other file and as they have always had.
Since no one else has reported this and all files on my local system are fine, I suspect the problem is in your installation somewhere.
Comment #2
Daedalon commentedThe problem may be related to using suphp, which causes Apache and thus the user to be run under the user's credentials. This is not the most common configuration.
I'm leaving the issue status untouched and return later if something relevant comes up.
Comment #2.0
Daedalon commentedMention that modules seem to differ in their chmod behavior on install/update