Some sites may need to show a different message. Maybe to include different information and/or use more human readable labels etc. A drupal_alter could allow modules to customise the message.

Comments

greggadsdon created an issue. See original summary.

greggadsdon’s picture

StatusFileSize
new902 bytes
greggadsdon’s picture

StatusFileSize
new900 bytes
btopro’s picture

What'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?

greggadsdon’s picture

It 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.

btopro’s picture

you 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.

greggadsdon’s picture

Yes, 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.

btopro’s picture

Ok 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.

greggadsdon’s picture

So 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?

btopro’s picture

or 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

greggadsdon’s picture

StatusFileSize
new778 bytes

Yeah, 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).

btopro’s picture

The alter is called after it's been cloned and contains the clone as well as the original

hook_replicate_entity_alter

function replicate_clone_entity($entity_type, $entity) {
  $clone = clone $entity;

  if ($clone) {
    // Let other modules manage the cleaning of the entity.
    foreach (module_implements('replicate_entity_' . $entity_type) as $module) {
      $function = $module . '_replicate_entity_' . $entity_type;
      $function($clone);
    }

    // Set the entity as new entity.
    $clone->is_new = TRUE;

    // Let other modules do special actions on each field.
    replicate_clone_fields($clone, $entity_type);

    // Let other modules do special actions on the global entity.
    drupal_alter('replicate_entity', $clone, $entity_type, $entity);
  }

  return $clone;
}
btopro’s picture

Your 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

greggadsdon’s picture

StatusFileSize
new791 bytes

I 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)..

anybody’s picture

Status: Active » Closed (outdated)

Drupal 7 is EOL.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.