Installed Message for the first time on 8.2.x-dev and PHP 7.0.7 resulting in WSOD

PHP Fatal error: Cannot use Drupal\Component\Utility\String as String because 'String' is a special class name in /home/solution/public_html/my-domain.com/modules/contrib/message/modules/message_example/message_example.tokens.inc on line 8

3 schema errors exist (on update-travis branch) as spotted by https://www.drupal.org/project/config_inspector

Namely:

• display.default.display_options.fields.message_bulk_form_1.action_title
• display.default.display_options.fields.message_bulk_form_1.include_exclude
• display.default.display_options.fields.message_bulk_form_1.selected_actions

This was first noticed on running tests for MessageUi:

Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for views.view.message with the following errors: views.view.message:display.default.display_options.fields.message_bulk_form_1.action_title missing schema, views.view.message:display.default.display_options.fields.message_bulk_form_1.include_exclude missing schema, views.view.message:display.default.display_options.fields.message_bulk_form_1.selected_actions missing schema in Drupal\Core\Config\Testing\ConfigSchemaChecker->onConfigSave() (line 98 of /Applications/MAMP/htdocs/d8.message-ui.upgrade/core/lib/Drupal/Core/Config/Testing/ConfigSchemaChecker.php).

$t = message_type_create('test', array(
    'description' => 'Type description',
    'argument_keys' => array(
        '!mid',
        '!rid',
        '!category',
    ),
    'message_text' => array(
      LANGUAGE_NONE => array(
        array('value' => 'Bla bla bla'),
      ),
    ),
    'language' => 'en'
));

$tw = entity_metadata_wrapper('message_type', $t);
$tw->save();

// In a different request
$t_check = message_type_load('test');
if (empty($t_check->message_text)) {
  dsm('what is going on?');
  dsm($t_check);
}

will display the message "what is going on?" and the dsm will show the message_text is now empty :(

Notice: Undefined offset: 1 in Drupal\message\MessageViewBuilder->view() (line 47 of modules/message/src/MessageViewBuilder.php).
Drupal\message\MessageViewBuilder->view(Object, 'full') (Line: 96)
Drupal\Core\Entity\Controller\EntityViewController->view(Object, 'full')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)

It is coming from this code, the list function 1st param is missing, I guess this was intentional, so any ideas?

// The partials are keyed with `partial_X`, check if that is set.
      list(, $delta) = explode('_', $field_name);
      if (isset($partials[$delta])) {
        $extra .= $partials[$delta];
      }

It's been almost a year and a half since 1.9.

Like inD7:

    $message_type = message_type_create('foo');
    $message_type->{$property} = array(
      'en' => array(
        0 => array('value' => 'english text'),
      ),
      'l0' => array(
        0 => array('value' => $text1),
      ),
      'l1' => array(
        0 => array('value' => $text2),
      ),
    );
    $message_type->save();

It seems that when doing $message->setArguments() we end up with our values under the key 0.

It should be $arguments = array('@foo' => 'bar') not $arguments = array(array('@foo' => 'bar'))

/admin/structure/views/add

Also under "Show" there isn't the Message option which will show the whole rendered entity.

Scenario: Creating a message and then enabling the locale module. Since the text is in und key the text won't display in the form since the text aren't belong to any language.

Solution: After the locale module is enabled a variable will be set. The variable help us to show a message that will notify the admin he need to copy the message text from locale to any other language.

I started again on a freshD8 install after our changes and have been debugging the form at admin/content/message/create/example-create-node again.

Good news, the call to $extra_fields->getComponents() is now returning the partials:

$partials = {array} [2]
 0 = "<p><a href='[message:user-url]'>[message:user-name]</a> created <a href='[message:node-    url]'>[message:node-title]</a></p>\r\n"
 1 = "<p>[message:node-render]</p>\r\n"

Problem is that the $extra variable used to populate the #markup in the build array is not accessing the partials as shown above.

Line 53 of MessageViewBuilder:
$extra .= $partials[$langcode][$delta];

In my case with langcode en there are no values at this index. The partials are being returned at numeric indexes, is this correct, or should they be returned by langcode or the D8 equivalent of 'und'?

The Message entity type provides several additional public methods. It would be nice if these were part of the MessageInterface for testing and mocking purposes.

I'm happy to do this as a PR once #39 is merged.

Right now in the code we still see the use of !, but in D8 this no longer seems to be the case.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Render%21FormattableMarkup.php/function/FormattableMarkup%3A%3AplaceholderFormat/8

By looking the documentation it's not clearly for me how to create the message_types properly using code.

1. message_example and message_og_example do it by calling entity_import, which is not what I'm looking for.
2. message_type_create on the other hand is not documented enough for me to figure out how to do it on my own. There is no explanation of the expected values inside $values array.

What is the branch origin/6 about?
Those commits look freaking ugly.... ;(

| * 8780e7d - (3 weeks ago) Push new test. - Roy Segall
| * fb0a995 - (3 weeks ago) Try something. - Roy Segall
| * 780038d - (3 weeks ago) Try? - Roy Segall
| * 137fbb0 - (3 weeks ago) Foo. - Roy Segall
| * 9f999fd - (3 weeks ago) bbbb - Roy Segall
| * 51ea82f - (3 weeks ago) serizlie. - Roy Segall
| * b5980f7 - (3 weeks ago) dd - Roy Segall
| * 11bf456 - (3 weeks ago) fff - Roy Segall
| * e4e031f - (3 weeks ago) ff - Roy Segall
| * 9b1db0c - (3 weeks ago) fo - Roy Segall
| * 2248317 - (3 weeks ago) ffff - Roy Segall
| * 31dbdac - (3 weeks ago) fff - Roy Segall
| * 878d2eb - (3 weeks ago) Try. - Roy Segall
| * a0b22d7 - (3 weeks ago) f - Roy Segall
| * af37611 - (3 weeks ago) anither try. - Roy Segall
| * 3963d6d - (3 weeks ago) Try 5.4 - Roy Segall
| * 0692357 - (4 weeks ago) Surfing bird. - Roy Segall
| * 8c8d637 - (4 weeks ago) Push. - Roy Segall
| * 8ded72d - (4 weeks ago) Maybe.... - Roy Segall
| * 26b4219 - (4 weeks ago) Try. - Roy Segall
| * dae7595 - (4 weeks ago) hmmm - Roy Segall
| * 7752ad2 - (4 weeks ago) Maybe? - Roy Segall
| * 8c21f2d - (4 weeks ago) Organize? - Roy Segall
| * ceaaa0f - (4 weeks ago) RRR - Roy Segall
| * 2d2953a - (4 weeks ago) Available types. - Roy Segall
| * 52e2120 - (4 weeks ago) bar - Roy Segall
| * 1fe9e3d - (4 weeks ago) foo - Roy Segall
| * d387415 - (4 weeks ago) foo. - Roy Segall
| * 590d23e - (4 weeks ago) Pushing debug. - Roy Segall

So, at this point we've been using Message for 4 years in Kickstart and outside of it, as well as helping the community use it.

There has always been some level of confusion regarding the relationship between Messages and Message Types. While types are standard Drupal terminology, they usually exist only to provide fields. Here, they have another purpose: to provide the template.

My gut feeling is that it would be much clearer for Message Types to be called Message Templates. That's their primary purpose, they hold the template, which then gets the tokens replaced, and then used (and / or saved as a message). The bundle aspect of it is secondary (especially since many/most messages have a need for the same two fields: the source entity, the body).

I'd also rename Message Type Categories to Message Template Groups, since it feels like "group" is more standard for this purpose than "category".

(e.g. MESSAGE_PURGE_LIMIT)

It should be enabled by default. When disabled, non token processing will happen.

It looks like Message entity does not provide revisions.

Would this affect many areas of the code if we follow the documentation to make an entity revisionable?

Is this something that can make it into Message on D7, through a contributed patch or otherwise, or will it make it into D8 only now?

Until now the message arguments were saved in the DB into the message objects. The disadvantages of it are:

1. The information for each message, value or callback, and if we need to maintain the value we need to iterate over the messages and update the value or change the arguments.
2. The information is shared to all the messages form the same bundle. Store this data in the DB for each message is a pretty much over kill and can live outside the DB.

This will affect the 8.x-1.x branch as well.

There are several places where current methods return either a string or an array based on values in an options array.

I propose in Drupal 8 that this change to be different methods on the entity object instead.

The getText() method on both message and message_type entities are where I'm currently encountering this while porting message_notify.

If that sounds agreeable, I can start on that work.

I'm trying to find a way to load a single delta value from the text field of a message entity in Rules, but I can't find out how. Is this currently not possible?

In message_example_tokens there is a use in the function message. We need to remove it before go over the other thigs.

It doesn't look so for me, it makes a lot of mentions to interfaces that aren't shipped with message.module anymore :(

On D8 branch in message.api.php, I presume the code in hook_message_view is an example and the hook function should not be called directly, but is $additional_field intentionally undefined?

function hook_message_view($message, $view_mode, $langcode) {
  $message->content['my_additional_field'] = array(
    '#markup' => $additional_field,
    '#weight' => 10,
    '#theme' => 'mymodule_my_additional_field',
  );
}

For two reasons:

1. It is not useful - I don't think anybody used this feature of pre-setting the arguments on message-type
2. I don't think it's even used in the code - or at least I couldn't find it in \Drupal\message\Entity\Message::getText

I'm not sure why this is at the moment, but you can see the correct return value of all EntityDisplayBase::getComponents called from EntityFormDisplay::buildForm for Node when visiting node/add/page.

The getComponents returns the following for $this->content including my custom field field_test:

content = {array} [10]
 body = {array} [4]
 created = {array} [4]
 field_test = {array} [4]
 path = {array} [4]
 promote = {array} [4]
 sticky = {array} [4]
 title = {array} [4]
 uid = {array} [4]
 langcode = {array} [4]
 revision_log = {array} [4]

The output for message when I visit admin/content/message/create/example-create-node is interesting. A breakpoint at getComponents is reached twice, firstly with the output for the partials in $this->content:

content = {array} [2]
 partial_0 = {array} [1]
 partial_1 = {array} [1]

...and it is reached a second time and dumps the custom field field_test which I added to the example_create_node message type, but it does not include the field_node_reference field or the field_published field.

content = {array} [1]
 field_test = {array} [4]

The EntityFormDisplay object has the correct fieldDefinitions though however at $this->fieldDefinitions:

fieldDefinitions = {array} [3]
 field_node_reference = {Drupal\field\Entity\FieldConfig} [34]
 field_published = {Drupal\field\Entity\FieldConfig} [34]
 field_test = {Drupal\field\Entity\FieldConfig} [34]

So, I'm not sure why this is happening yet, perhaps a setComponent is not being called correctly somewhere. I might get to look at this again later in the week.

Notice: Undefined index: en in Drupal\message\MessageViewBuilder->view() (line 43 of modules/message/src/MessageViewBuilder.php).

There may be a problem with obtaining the partials (Line : 25)

There entity_get_display is also deprecated on Line : 39.

Steps to reproduce:

1. Enable message example and devel generate
2. Generate dummy nodes
3. Go to the messages page and you'll see "Array" instead of the message text it self.

This becomes a real issue when you have entity reference pointing on message type because entity reference using internal ID instead of entity name. This means that each time I deploy my code and revert features I'm loosing data.
Will try to figure out a solution in the morning...

There's probably an automated way for this, no?

I think the current state of this module is ready for an alpha. It would also be good to push the current repo back up to drupal.org for greater visibility.

There's no reason for a D8 module to every use array().

@RoySegall Some tests are under tests, and some are under src/Tests. Is there a reason, or an oversight?

admin/structure/message/manage/example_create_node

with message ID DESC by default

Created a new view mode "user_notification" and created a template file "message--user-notification.html.twig" as suggested and placed in the template directory of same module.

Control is not coming to the suggested template file.

I am pretty sure that the above methods are not working and while perhaps related, I believe getOwnerId() is not working either.

I noticed this as after calling these methods in submitForm() in Message UI the entity object does not reflect the new values, either on a new or existing message entity. See usage in: https://github.com/mccrodp/message_ui/blob/8.x-1.x/src/Form/MessageForm.php#L178

When stepping through this it seems to behave differently than the node entity when it calls it's setOwnerId() for instance.

Currently only the first argument is being used.

Furthermore, we seem to iterate over the tokens, without checking if it was explicitly disabled, as we do in D7 for performance reasons.

Currently when enabling the token module we are not getting tokens related to Message. We used to het it via D7's entity_token.

@RoySegall @jhedstrom do you happen to know if there's a replacement for this?

My goal is to remove as much as possible from message_example_token_info()

This feature in D7 was meant to be able to create custom message types with their own fields. AFAIK only commerce guys used it.

Now in D8 the message type is a config entity, so anyway it's not fieldable. I think we an remove this unused feature and simplify the module a bit.

(cc @bojanz)

When referencing to messages using a an autocomplete handler we get SQL error since we don't have a label key defined in the entity info.

@RoySegall / @jhedstrom I did a diff between these branches (attached).

If you cat update-rc1_update-travis_diff.txt it should display with color. Can you please let me know which changes should be preserved and if you can see any issues relating to this test error referenced from #39 (comment)

Following this I'll create a PR as requested in the issue above.
update-rc1_update-travis_diff.txt

Hi,

I have a website where we have to store around 1.200.000 entities daily, those entities can be discarded after 24h.
Those entities are composed of a 3 fields ( text + 2 integer list ).
Currently, i used the message module for those entities but with the increasing amount of entities created each day, the purge cron task is taking more and more processing time.
The purge cron task is set to run every minutes, deleting 2000 row each time, using drush elysia cron task.

How can optimize the purge of those entities or at least make it easier on the proc ?

At the moment we have 2 paths for Message Content.

• /admin/content/message
• /admin/content/messages

@RoySegall - as we saw earlier core content paths may not be consistent re: plural vs. singular, e.g. "comment" & "files" in the path.

We need to choose one of these for consistency:

• See singular used in routing yaml and elsewhere.
• See plural in views yaml:
  "./message/config/optional/views.view.message.yml:495: path: admin/content/messages"

Notebly remove the token integration, as we already have token module exposing most of it

Further to discussion, it looks like message.html.twig is unused unlike it's tpl.php predecessor in D7.

It should be removed if so and perhaps we can include in Message UI if needed.