Closed (outdated)
Project:
Replicate UI
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
7 Sep 2016 at 14:07 UTC
Updated:
28 Oct 2025 at 08:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
greggadsdon commentedComment #3
greggadsdon commentedComment #4
btopro commentedWhat's an example message you are wanting to override this to? Seems a bit overkill for a message to have an alter behavior to it. Would https://www.drupal.org/project/stringoverrides make more sense to globally override the message?
Comment #5
greggadsdon commentedIt does seem that way yes. I don't think I could change the data with stringoverrides though.
The message would be something like 'Replicated $field_collection_type: %admin_title'. Using data from the replicated entity in the message.
Comment #6
btopro commentedyou can still target like:
%type (%id) has been replicated to id %new!
and then use the same tokens in the new message:
Replicated %type: %new
Are you bringing along other data? I'm not really against adding it this just seems overkill for 1 message to be posted.
Comment #7
greggadsdon commentedYes, I'll be adding different data into the message, so different tokens.
Basically I want to use names/labels in the message, from custom fields in this case, as it's nicer for the users who will be using the replicate functionality and will mean more to them than the ids.
I think if anyone else wanted to do this it would likely be very different data in each case which they want to bring in so an alter could be the best solution.
Comment #8
btopro commentedOk that makes more sense. Could it make more sense to have the message able to be disabled as a setting? Then you could use normal form_alter hooks or hook_replicate_entity_alter (from replicate module) to fire off your message you are looking for.
Comment #9
greggadsdon commentedSo we could add another submit callback perhaps to fire message? I initially thought that we wouldn't know if the replication was successful but I see that the new id does go into form state. Yeah that does probably make more sense. How might the setting be passed in?
Comment #10
btopro commentedor jumping in on hook_replicate_entity_alter directly and then you have full access to any entity right after replication and can also make it specific to type if needed
Comment #11
greggadsdon commentedYeah, so good options. hook_replicate_entity_alter would be before the clone is saved though.
What about something simple like this? You could set in form_alter (while perhaps also adding your submit callback).
Comment #12
btopro commentedThe alter is called after it's been cloned and contains the clone as well as the original
hook_replicate_entity_alter
Comment #13
btopro commentedYour proposed patch would provide a solution I like more where you could just set that flag and then it hides the message. hide_message could conflict w/ the rest of the universe of projects so maybe like replicate_ui_hide_message
Comment #14
greggadsdon commentedI was just thinking that you wouldn't have an id for the clone, so you wouldn't be able to use the new id in the message like the default message. Also I'd feel happier giving a "success" message once there is proof that it's saved (so we don't give the message if it breaks during saving for whatever reason)..
Comment #15
anybodyDrupal 7 is EOL.