CSM doesn't play nice with the Omega theme, so stop storing stuff in $messages; create a dedicated session variable (was "Display of node ID")

That shouldn't be displayed. I've seen that few time in dev version before releasing beta3. Anyways, any chance you could provide me steps to reproduce it? Any settings or additional modules what you r using? That will be very helpful.
Thanks

Just a though - have you flush caches just to see if it makes any difference?

Hi @Firewolf,

I've installed a fresh copy of drupal with all the modules listed above. I can't reproduce it. Any chance you could give me some details about the csm settings? When actually you getting the nid(create, update or delete?) Also what user role are you getting the message and r u getting any errors in logs?
Thanks

Hi @stefank,

I think node ID is shown when node_save() is used in the custom module. Hope that helps.
Thanks.

Closing this as we can't reproduce it; also I'm pretty sure that node_save() isn't called anywhere in the module. More than happy to re-open if the bug can be reproduced.

Same issue for me.
In my Ajax call back I am updating my node with node_save(), but the status message is not set. so it is adding the status message : $messages->add($node->nid, 'csm');.
So node Id is printing when I refresh my page. Can you please provide a solution for this.

Same issue too.
Node id is displayed and the message is the default one.

I had same issue, but created the patch.
Now all works good for me.

The issue was because the module uses hook_node_update to set message.

CSM module sets it's message with NID that should be replaced with message from module's settings.
When we update node manually CSM replaces internal messages.

So when we use node_save in any other module, no message is set. CSM creates it's NID message but cant replace it by custom message.

#8 works, thanks!

Patch committed to 7.x-1.x (with some tweaks to get it to work properly). Thanks!

My sorry, but issue remains in 7.x-1.0-beta7. Installing latest dev does not solve it.

Hi @sumerian: could you give me a little bit more information to help me fix this bug, please? A screenshot of what you are describing would be really helpful, as would a list of any modules you are using that you think might be causing this issue to occur. If you could try switching off a few of these modules until the issue disappears that would be great; I can then try to recreate the issue on my development environment.

Hi @jim0203 and thanx for rapid reply!
Here is my drush pm-list output. And a screenshot with nid (510) and default node creation message (a green one). Tomorrow I'll try to make some of modules on-off to make things clearer.

Thanks! I will get onto this as soon as I can. Any further troubleshooting you are able to do would be really helpful :)

Okay, I think I've managed to work out which modules you currently have enabled. Pm-list output follows; can you check this to make sure I've got everything (won't be relevant if I manage to recreate the issue!)

I'm guessing that ctoolspopups and mymodule are custom modules?

With the modules listed above installed I can't recreate the bug when setting custom create/update/delete messages for the "Article" node type with beta7, so I've changed the status back to "postponed".

Perhaps this is being caused by a specific configuration you have running on your site, or at the theme level? More than happy to get this fixed if you can help drag the bug down.

A bit of background information:

When a node is created, updated, or deleted a function called _csm_node_ops($node, $op) is run. This stores the $node in the variable table, under the variable name csm_node_temp_nid (where nid is the node id number). It also adds a creates a new message which contains the nid, but this message is intended never to be displayed -- it's just a way of storing the nid so it can be retrieved later, and ultimately used to retrieve the full $node from the variable table...

...which happens in csm_message_alter(&$messages), which is the implementation of the hook_message_alter() hook as provided by the messages_alter module:

$nid = $messages->messages['csm'][0];
$node = variable_get('csm_node_temp_' . $nid, NULL);

At this point, the fake message is still set. A few lines down, it should be deleted:

$nid_message = $messages->match("/" . $nid . "/", 'csm');
$messages->remove($nid_message);

These lines are there twice, once for when no message is being changed and another time when messages *are* being changed.

So, a quick and dirty fix here would be for you to ensure that before this function returns, all of the messages stored in $messages->messages['csm'][$i] are destroyed. messages_alter provides a way to do this, or you may be able to hack it by hand. Have you got the skills to enable you to do this?

I think, however, that a better fix would be to stop storing this stuff in the $messages object in the first place, and to instead use a dedicated session variable (which is essentially what I'm doing by storing all this stuff in $messages). So that's what I'll do.

Hey Jim! I've done some research. This bug appears to be concerned with Omega theme.
So to reproduce it you can install Drupal, Omega, CSM, and make Omega default theme. And that's it!

Great work, thank you! I installed Omega and the bug happened immediately.

I'm going to try my proposed solution (storing stuff in a custom $_SESSION variable rather than as a dummy message) before looking too deeply into this, as it needs to be done anyway and I'm pretty sure it will fix this bug. I've got an extra feature that I want to include in the next dev release, too, and that's almost ready so I'll push the whole lot to dev as soon as it's ready, and post here so you can test.

This should now be fixed in the dev release and beta8. I was having some problems getting the module to work with Omega, but I think this is to do with my dev environment. Please test and post any further issues.

Hi Jim! Much thanx to you for your work!
I've done testing of latest dev. It does work with Bartik (string changes, everything is OK) but it does not with Omega. Nid went away but the message remains default (Article qwert has been created.)

Ha, so what looked like a deeper Omega bug seems to be independent of my dev environment.

My initial investigation suggested that for some reason csm_message_alter() (the instance of hook_message_alter() that CSM uses to change messages) was not always firing when Omega is set as the default theme. I have no idea why this might be the case, but I will create a new issue to cover this bug.

@sumerian, can you confirm whether CSM *ever* changed messages when Omega was set as the default theme? For example, when CSM displayed the nid in a message, did it also change the status message to be what you'd set it to? Because as it stands I don't think that the hook that fires to change messages works when Omega is set as the default theme ...

> can you confirm whether CSM *ever* changed messages when Omega was set as the default theme?
nope, never.
I can confirm that with Omega as default theme csm_message_alter() never fires.

@sumerian: great, thanks! So it seems that Omega caused two problems with CSM (or vice versa): the stray "nid" messages (now fixed), and the fact that csm_message_alter() never fires -- or, more precisely, that no hook_message_alter() that feeds back in to the messages_alter.module ever fires.

I'll get on with fixing the second issue now.

@sumerian: I may have a solution for you that gets CSM working with Omega. Can you check out #2622252-5: hook_message_alter() doesn't always fire when the Omega theme is used and comment in that thread, please?