Closed (fixed)
Project:
Custom Submit Messages
Component:
Code
Priority:
Critical
Category:
Task
Assigned:
Reporter:
Created:
29 Jan 2010 at 18:46 UTC
Updated:
13 Feb 2010 at 18:00 UTC
I'd start with a hook form alter on the content type config form. Each content type could have two fields: one for created, one for updated. Store these strings/patterns (if you hook in tokens, which you should) in the variables table (using a pattern like csm_update_blog, csm_save_page). If these are output using t() then the language stuff will be taken care of.
Make sense?
T
Comments
Comment #1
tom_o_t commentedJust noticed mcjim's comment on Twitter about using drupal_get_messages() to intercept the default messages that the Drupal module outputs when a node is saved/updated. Very good idea. Will be a bit hacky to intercept and remove the right ones, but totally possible.
Comment #2
jim0203 commentedThe problem here is the output part: how should the original message be killed and replaced with the new message?
Using the technique that String Overrides deployed is what I'm doing at the moment. This allows me to replace a dynamic string like '@type %title has been created' with '%title, a node of type @type, has been created' by just creating the appropriate locale entries in the variables table.
The problem with trying to localise this technique for individual node types is that the node module gives us only two strings for all node types: one for new nodes, and one for updated nodes.
See node.pages.inc ll. 461-468:
So, using the tranlsation method, there is nothing in the original string to tell the translation system what node type it is translating from: at the point that translation takes place, we're still working with @type and %title.
By the time we get to the theme layer, where I could kill the default message and replace it with my own message (probably using hook_theme_registry_alter()), we're dealing with the string as it is going to appear in the page: i.e., the @type and %title have been replaced. So if I kill the message at that point (when we can be node-type specific) it's difficult to put the dynamic stuff back in.
One solution I did come up with is to do both of these things: do a standard locale/string overrides swap that changes '@type %title has been created' so that by the time it's got to the theme layer, it's still possible to pick out type and title before the message is killed. Then the new message can be built and displayed. For example, '@type %title has been created' could be replaced with '@@type %%title has been created', as long as everything is escaped properly. I don't know if this would work but if no-one else knows then I'll give it a crack.
Comment #3
jim0203 commentedThinking about this a bit more, I don't think the translation technique that SO uses is the way to go at all.
I can just kill the original message in the theme layer (it'd be easy to find as it'd be of a standard form) and then cobble together a new version of the message from what's in $form. It'll need a bit of work to get the UI to work properly so that people can still use @type and %title, but I think I see how this is going to work now!
Comment #4
mcjim commentedYes! You're on to something there...
hook_nodeapi knows when the node has been updated, so maybe set the brand new message there? Grabbing the custom bit from wherever you've stored it.
And then kill the boring default message at whichever point you find convenient :-)
Comment #5
jim0203 commentedI think I've got a solution...
...searching the messages will reveal whether a message has been set, as they have a standard format (especially if they've been translated to something wacky). Then, $_SERVER['HTTP_REFERRER'] gives the actual node id of the node that's been saved or edit (give or take a bit of parsing). From there you can get the node title and type, and build the message. In fact, this would allow anything in the node object to be included in the message.
The only extra strain is the check each time a page is loaded to see if there's a message to be translated, but this can be minimized.
Comment #6
jim0203 commentedJust about to roll the first version. Actually spotting the messages is the hacky part, but it's all done in the theme layer with no use made of the original String Overrides/translation techniques.