edgeryders / edgeryders-commons Goto Github PK

In file sites/all/modules/edgeryders_nav/css/edgeryders_nav.navbar.icons.css, ll. 17 and 21, there is a reference to directory 5181c6 for looking for the Edgeryders logo. That directory does not exist, so when that link is used (currently only on the front page, where the "active" CSS class is set on that navbar item) it will be broken.

This path element has been removed on the live site without committing to git for now. It should be properly included into a commit to fix it, if just removing it is the fix indeed.

Also, the separate CSS definitons for .active and :active selectors in sites/all/modules/edgeryders_nav/css/edgeryders_nav.navbar.icons.css is either confusing or not needed (after referencing the same logo file as in the definitions above them). Please explain in a comment why it's needed, or otherwise merge with the definitions above.

After the exporting of features, installing a new version, and re-importing the features, the URL alias patterns settings got overwritten with defaults. They should be included into feature exports in the future.

Specifically, the settings to fix are:

• "Content paths: Default path pattern": [node:og-group-audience:first]/[node:title] instead of groups/[node:commons-groups-first-group]/[node:title]
• "Content paths: Default path pattern for Group": [node:title] instead of groups/[node:title]

The following URL alias patterns are still correct, they were not overwritten by the new version:

• "File paths: Default path pattern": files/[file:name]
• "Pattern for all page paths": content/[node:title]
• "Pattern for all task paths": [node:og-group-audience:first]/task-[node:nid]
• "Taxonomy term paths: Default path pattern": [term:vocabulary]/[term:name]
• "Taxonomy term paths: Pattern for all Behaviors paths": making-lote3/activities/[term:name]
• "User paths: Pattern for user account page paths": users/[user:name]
• Empty string as value for all other available URL alias patten fields.

After the upgrade to Drupal Commons 7.32 (commit 2d458e3), notification e-mails for @mentions are sent indefinitely. Every five minutes, I got around 40 notification e-mails because of being mentioned in this comment. Numbers varied: 42, 41, 37, 38, 44, 46, 38 etc. around 14:00 and up to 97 earlier in the day. So it seems it is simply sending notifications as fast as possible until running into some timeout.

The e-mails stopped immediately when I disabled module edgeryders_mentions_notifications, so the problem is there. Let's keep this disabled until the issue is fixed.

The problem with message digests not being sent on the edgeryders.eu live site is this: the cronjob sending the message digest e-mails fails with:

WD php: EntityMetadataWrapperException: Unknown data property message_header. 
in EntityStructureWrapper->getPropertyInfo() (line 335 of 
[…]/profiles/commons/modules/contrib/entity/includes/entity.wrapper.inc).

This error does not appear in any log, but can be produced in the terminal like this:

1. Reset the "last run" setting to allow testing again (we set the last run to two days ago, enough for another daily digest to be sent):

   drush variable-set "message_digest_1 day_last_run" $(date +"%s" -d "-2 days")
   

2. Run the message_digest cron task directly with:

   drush php-eval "message_digest_cron();"
   

The error can be prevented (and HTML digest e-mails can be sent successfully) by deleting two lines in message_digest/plugins/notifier/abstract.inc from commit 3e328b7:

l. 119: $header_text = $message->getText($langcode, $options);
l. 127: $footer_text = $message->getText($langcode, $options);

The problem is not related to missing to run the (updated) install module function from the above commit. It persists even after making a fresh installation.

I assume the problem is that messages created before the installation of (this version of) message_digest do not have the message_header and message_footer field. Means: mark all pending messages in table message_digest as "sent" when doing the module installation.

However, I will have to check if that's really the problem (means, if digests are now sent even with the above lines enabled, after I marked all previous message_digest entries manually as sent). Also, since this only happens on update, it will only become relevant when contributing the addition of header and footer upstream to the module.