🇵🇹Portugal @jrochate

Thanks. That solved the error I was having, even after uninstalling the module

Thanks.

I was getting this fatal error, and the #5 solved it.

jrochate → created an issue.

jrochate → created an issue.

This MR is setting charts requirements to 5.1.6 but the module is still on 5.1.3

diff --git a/composer.json b/composer.json
index e4d087cf381d9ccac41fb7a9d9a1632b179f02a4..6017dd455582b55385463a5502a857abb7cdf7a5 100644
--- a/composer.json
+++ b/composer.json
@@ -18,6 +18,6 @@
   },
   "license": "GPL-2.0-or-later",
   "require": {
-      "drupal/charts": "^5.0.3"
+      "drupal/charts": "^5.1.6"
   }
 }

Solved on the related issue

There are no more PHP warnings when editing ECA model, and the select box with Entities still show the flat list with all of them.

Thanks!

Awesome. I'm ready to test that MR when it's available .

I have edited the Plugin EntityFinder, on line 386 and invalidated the PHP with an implode() function on getLabel.

With that, the warning about Array to String on editing ECA models, disappeared.

I think you should improve that issue and try to explain a little more why you think an ECA error message is related to tamper :)

I think the problem is near,. because if I invalidate the getLabel with a forced PHP error, por exemple using implode(), then the warnings go away.

To get more deep on this, I will join my colleague on Monday to trace the code and be sure about it.

In my case, the $entity_type->getLabel() does return a string.

Maybe there something else on the structure. I will take a look on Monday.

Ok, will do so. I will get back here with more info.

thanks.

jrochate → created an issue.

jrochate → created an issue.

Drupal 10.4 + pathauto 1.13 + upgrade to rh 2, and the patch was still needed.

The error was the same as post title:

[error] The "" plugin does not exist. Valid plugin IDs for Drupal\rabbit_hole\Plugin\RabbitHoleBehaviorPluginManager are: access_denied, page_not_found, display_page, page_redirect

Thanks manish.upadhyay

hi @megachriz

Yep, that nails it. Thanks.

Same as #112, using Drupal 10.4 and PHP 8.4.

When editing Media, the image it's no there, but it can be seen on files and on the related node.

We're almost there... With ver 2.1 custom_tag module, we can achieve rel=alternate and href=link. It just misses the type tag.

Thanks. #5 tip solved the lagging version.

We are on Drupal 11.0.5 and yet this message still marks the Drupal 10.3 as Outdated

If we have 4.0.3 that is still supported, on Drupal 10.3, the installation should not be marked as outdated.

Oh, now I can add that secondary axis, but in very specific conditions.

It would be good if:

1. I could had several columns, and just the last one into the secondary.
At the moment it's mandatory to have just two columns, where the first goes to axis1 and the second goes to axis2

2. I cloud have a distinct chart type for the secondary axis, e.g., bars for the axis1 and line for the axis2
At the moment, it's the same chart type for both axis

Anyway, thank you very much for your kind reply.

Do you think it will be possible to achieve the previous 1. or 2. good-to-have stuff?

thanks.

After some digging we found out that it was a very specific use case in token_or → that was not having consequences until we used ECA.

So it's has nothing to do with ECA, but it has to be improved in token_or side when using a specific duplicated token that we had.

Thanks anyway.

jrochate → created an issue.

I have this problem also.

When rejecting cookies, or not saving cookies, the SESSIONID is non existent. The SQL tries to save a new line using null value on the Sid column, and if there is already another non-cookie saved, the primary key error occurs.

Does not work on current dev.

Patch works great on dev. Thanks.

Doesn't work on latest 1.13

I got the same situation using BEF 6.0.6, and I have reroll the patch for BEF 6.x version.

It really make difference when using chosen search input. Please review.

This is getting a little messy.

The #12 works fine on module's 1.5 and 1.6 version.

Thanks @jan! For me it doesn't break now, when listing users and in other places where I was having memcache's WSOD.

I'm sending a simple patch just to keep speed up people who would like to test it also.

Same here, for example when listing users.

Same here with #11. It works with ECA2, and also the problem of not being able to use a locally defined token with an e-mail as value.

For now I can hardcode the e-mail address, but it would be great to use a local token instead of hardcode of an entity token.

Same here. Version 1.6 has the problem with special chars. Patch in #15 for the 1.5 version works fine.

I was having this same problem.

Even forcing to update records on every run, this error always poped-up.

I found out that when a referenced entity did not exists, instead of feeds reporting that (as usual) it would break.

I solved it by guarantying that the referenced entity always exists before running the feed that was rising the error.

Maybe this can be helpful to anyone who comes here with the same problem: be sure that referenced entities (nodes) already exists.

Does not work with current DEV branch.

I'm also having this problem:

webform 6.2.x
drupal 10.3

    data_evento_inicio:
      '#type': datetime
      '#title': 'Data do Evento'
      '#title_display': inline
      '#required': true
      '#format': simple_datetime_alt
      '#date_year_range': ''
    data_evento_fim:
      '#type': datetime
      '#title': Fim
      '#title_display': inline
      '#required': true
      '#date_min': '[webform_submission:values:data_evento_inicio:raw]'
      '#format': simple_datetime_alt
      '#date_year_range': ''

I think the best is to use raw as should result in an UNIXTIMESTAMP.

But I'm getting the error:

Unable to render elements, please view the below message(s) and the error log.

The timestamp must be numeric.

Is it impossible to reference previous submissions fields on this validation rule?

Can't find out the limitation. TIA

same here... This message keeps the drupal installation in an outdated state.

The Linkit module had a similar problem, that we could patch it like 💬 Update module erroneously recommends conflicting update to 6.1.x for sites on Drupal 10.0.x or lower Closed: works as designed

Still the same problem using Drupal 10.3 and latest IMCE

Patches don't apply work on 10.3

Same here, but not multi-site.

Currently none of the patches above works: 1.11

Thanks for the commit. It would be nice to give credit to lolgm since he has made the MR.

jrochate → created an issue.

Hey @ThuleNB, try this one 🐛 TypeError: Illegal offset type in isset or empty Needs review , I think it will fix your error.

What about this issue 🐛 Compability issue with BEF 6.0.3 Needs review ? The patch it's similar but a few more instructions.

I have the same situation, and maybe it's related to 🐛 Changes on clone are reflected on the original node also Postponed: needs info .

I am not using site studio and I got the same problem:
- when cloning a node with Layout Paragraphs, we can see that we got a duplication of IDs

Clones node

     "x-default" => array:27 [▼
        0 => array:2 [▼
          "target_id" => "5747"
          "target_revision_id" => "111694"
        ]
        1 => array:2 [▼
          "target_id" => "5748"
          "target_revision_id" => "111695"
        ]
        2 => array:2 [▼
          "target_id" => "5749"
          "target_revision_id" => "111696"
        ]
        3 => array:2 [▼
          "target_id" => "5750"
          "target_revision_id" => "111697"
        ]
        4 => array:2 [▼
          "target_id" => "5751"
          "target_revision_id" => "111698"
        ]
        5 => array:2 [▼
          "target_id" => "5752"
          "target_revision_id" => "111699"
        ]
        6 => array:2 [▼
          "target_id" => "5765"
          "target_revision_id" => "111700"
        ]
        7 => array:2 [▼
          "target_id" => "5766"
          "target_revision_id" => "111701"
        ]
        8 => array:2 [▼
          "target_id" => "5767"
          "target_revision_id" => "111702"
        ]
        9 => array:2 [▼
          "target_id" => "5753"
          "target_revision_id" => "111703"
        ]
        10 => array:2 [▼
          "target_id" => "5754"
          "target_revision_id" => "111704"
        ]
        11 => array:2 [▼
          "target_id" => "5755"
          "target_revision_id" => "111705"
        ]
        12 => array:2 [▼
          "target_id" => "5756"
          "target_revision_id" => "111706"
        ]
        13 => array:2 [▼
          "target_id" => "5757"
          "target_revision_id" => "111707"
        ]
        14 => array:2 [▼
          "target_id" => "5758"
          "target_revision_id" => "111708"
        ]
        15 => array:2 [▼
          "target_id" => "5759"
          "target_revision_id" => "111709"
        ]
        16 => array:2 [▼
          "target_id" => "5760"
          "target_revision_id" => "111710"
        ]
        17 => array:2 [▼
          "target_id" => "5761"
          "target_revision_id" => "111711"
        ]
        18 => array:2 [▼
          "target_id" => "5762"
          "target_revision_id" => "111712"
        ]
        19 => array:2 [▼
          "target_id" => "5763"
          "target_revision_id" => "111713"
        ]
        20 => array:2 [▼
          "target_id" => "5764"
          "target_revision_id" => "111714"
        ]
        21 => array:2 [▼
          "target_id" => "5768"
          "target_revision_id" => "111715"
        ]
        22 => array:2 [▼
          "target_id" => "5769"
          "target_revision_id" => "111716"
        ]
        23 => array:2 [▼
          "target_id" => "5770"
          "target_revision_id" => "111717"
        ]
        24 => array:2 [▶]
        25 => array:2 [▶]
        26 => array:2 [▶]

Original node, now with the clone paragraphs back to it:

      "x-default" => array:42 [▼
        0 => array:2 [▼
          "target_id" => "5716"
          "target_revision_id" => "112067"
        ]
        1 => array:2 [▼
          "target_id" => "5717"
          "target_revision_id" => "112068"
        ]
        2 => array:2 [▶]
        3 => array:2 [▶]
        4 => array:2 [▶]
        5 => array:2 [▶]
        6 => array:2 [▶]
        7 => array:2 [▶]
        8 => array:2 [▶]
        9 => array:2 [▶]
        10 => array:2 [▶]
        11 => array:2 [▶]
        12 => array:2 [▶]
        13 => array:2 [▶]
        14 => array:2 [▶]
        15 => array:2 [▶]
        16 => array:2 [▶]
        17 => array:2 [▶]
        18 => array:2 [▶]
        19 => array:2 [▶]
        20 => array:2 [▼
          "target_id" => "5741"
          "target_revision_id" => "112087"
        ]
        21 => array:2 [▼
          "target_id" => "5747"
          "target_revision_id" => "112088"
        ]
        22 => array:2 [▼
          "target_id" => "5748"
          "target_revision_id" => "112089"
        ]
        23 => array:2 [▼
          "target_id" => "5749"
          "target_revision_id" => "112090"
        ]
        24 => array:2 [▼
          "target_id" => "5750"
          "target_revision_id" => "112091"
        ]
        25 => array:2 [▼
          "target_id" => "5751"
          "target_revision_id" => "112092"
        ]
        26 => array:2 [▼
          "target_id" => "5752"
          "target_revision_id" => "112093"
        ]
        27 => array:2 [▼
          "target_id" => "5753"
          "target_revision_id" => "112094"
        ]
        28 => array:2 [▼
          "target_id" => "5754"
          "target_revision_id" => "112095"
        ]
        29 => array:2 [▼
          "target_id" => "5755"
          "target_revision_id" => "112096"
        ]
        30 => array:2 [▼
          "target_id" => "5756"
          "target_revision_id" => "112097"
        ]
        31 => array:2 [▼
          "target_id" => "5757"
          "target_revision_id" => "112098"
        ]
        32 => array:2 [▼
          "target_id" => "5758"
          "target_revision_id" => "112099"
        ]
        33 => array:2 [▼
          "target_id" => "5759"
          "target_revision_id" => "112100"
        ]
        34 => array:2 [▼
          "target_id" => "5760"
          "target_revision_id" => "112101"
        ]
        35 => array:2 [▼
          "target_id" => "5761"
          "target_revision_id" => "112102"
        ]
        36 => array:2 [▼
          "target_id" => "5762"
          "target_revision_id" => "112103"
        ]
        37 => array:2 [▼
          "target_id" => "5763"
          "target_revision_id" => "112104"
        ]
        38 => array:2 [▼
          "target_id" => "5764"
          "target_revision_id" => "112105"
        ]
        39 => array:2 [▼
          "target_id" => "5765"
          "target_revision_id" => "112106"
        ]
        40 => array:2 [▼
          "target_id" => "5766"
          "target_revision_id" => "112107"
        ]
        41 => array:2 [▼
          "target_id" => "5767"
          "target_revision_id" => "112108"
        ]
      ]

At the moment, the MR!416 is working fine on 1.1.x.

I can't firmly test it on 2.0.x-dev for now.

same here, #7 solves.

I'm sorry, but I think that's not the solution.

You would have a warning about the non existing dimension of the array.

Also I don't the real implications of having the $field_target_bundles empty processed, instead of just skipping the code when empty.

I think we must wait for someone with a better knowledge about PbT. This is an access module, we shouldn't patch it to solve basic PHP errors without knowing the implications of some patch decisions.

If there is no suggestion from someone more used to PbT, I will post my own patch in a couple of days.

jrochate → created an issue.

Hi @joseph.olstad

I think @pianomansam should get credit on this fix, that would be good for him and his organization.

Thanks. +1TBC

This issue also solves the problem of not creating a revision when the widget is hidden.
+1TBC

This patch isn't perfect, but we could get a level of control in paragraphs.
Sometimes I would need to change from visible to !visible to make the rules work, but they worked.

It would be good to have it committed or, at least, re-rolled to the current dev.

Thanks :)

Thanks @Arantxio. That works on current RC19.

I think it's a good way of dealing with the problem.

I will try and see if a views sort handler can be done here, and thank you for your reply.

I have checked the other issue, and I think the OP is having problems in using multiple tables that come from distinct views blocks, and he has problems in sorting the columns.

here the problem is not specific to Table but views in general, where we don't have the handler available.
So I would keep it separate, if you don't mind.

if we follow the recommend way to replace previous method, then we can fix it.

Read more here: https://www.drupal.org/node/3349759 →

Patch in attach the solve the problem.

If I downgrade from 1.x-dev to 1.7, it works as expected, where the roles are limited to the ones definied on the main Permissions Drupal area.

jrochate → created an issue.

This module Entity Role View Mode Switcher → is another nice example of what we could do in ECA:

- the module sets some rules about roles and view modes
- using the hook hook_entity_view_mode_alter() like we talked before, they get the node rendered according to the rules.

The .module is basically just this:

use Drupal\Core\Entity\EntityInterface;
use Drupal\entity_role_view_mode_switcher\Util\ViewModeSwitcher;

/**
 * Implements hook_entity_view_mode_alter().
 */
function entity_role_view_mode_switcher_entity_view_mode_alter(&$view_mode, EntityInterface $entity, $context) {
  $view_mode = ViewModeSwitcher::switchViewModes($entity, $view_mode, \Drupal::currentUser()->getRoles());
}

is we got this working on ECA, this module could be easily replaced and "extended", since we would get all the Conditions that ECA offers.

Now it works.

When I added this patch, I got another error and now it's fatal:

TypeError: Drupal\symfony_mailer_log\Plugin\EmailAdjuster\LogMail::Drupal\symfony_mailer_log\Plugin\EmailAdjuster\{closure}(): Argument #1 ($address) must be of type Drupal\symfony_mailer_log\Plugin\EmailAdjuster\AddressInterface, Drupal\symfony_mailer\Address given em Drupal\symfony_mailer_log\Plugin\EmailAdjuster\LogMail->Drupal\symfony_mailer_log\Plugin\EmailAdjuster\{closure}() (linha 124 de /var/www/(...)/web/modules/contrib/symfony_mailer_log/src/Plugin/EmailAdjuster/LogMail.php).

I have made a small array test to avoid null / empty $data array.

I have tested that module, and also checked the source code, and that is very hard do extend.

We would need to patch it very hard in order to get "set weight", since it's not pluggable.

To that kind of work, it would be preferable to make a new View sort handler specific to workflow.

namespace Drupal\workflow\Plugin\views\sort;

use Drupal\views\Plugin\views\sort\SortPluginBase;

and then explore from here.

I don't know workflow module to make this work quickly. What do you think about this approach?

I had this exact problem, after updating to Drupal 10.2 and ECA 1.1.5 and ECA Tamper 1.0.5

After moving to ECA Tamper 1.0.x, with this commit, it worked again. Thanks all.

hi @johnv. thank you for your time, but that suggestion doesn't work for the use-case initially defined:

- I have a workflow with states. And that states can haver an order defined by weight
/admin/config/workflow/workflow/my_wf/states

- I would like to build a view where the content is sorted using states weight and not states title

Using a relationship, I can only relate to workflow_transition, and that won't work since I don't have weight in there.

So what would work is a relation to the config since states are configs and not entity... in theory.

@Klemendev that issue is already on the related section of this issue (check on the left), and also referred by #10.

Actually I had to add a check for boolean value in order to work.

Something like the patch below, applied after the above commit.

Tamper was sending an error message on line 100, FindReplace, because of a value of "true" that wasn't numeric nor string.

jrochate → created an issue.

After analysing the source code, I can see that this situation wouldn't work as initially thought.

Closing because won't use it the module soon, and don't have much time to propose patches to solve the problem.

jrochate → created an issue.

Thanks 🐛 $colorboxAttachment must not be accessed before initialization Needs review , that quickly solved the PHP error I was getting.

On this use-case I have an entity reference field that links to another entity. When I setup the formatter "Colorbox FF", I get this default options:

Style: Default
Link to Content
Width: 500
Height: 500
iFrame Mode: Yes

I think that's ok, but when I go to node display, the entity reference field gets the title NOT FROM the referenced node, but from the viewed node itself!

Something like:
Node A has Field X, entity referenced to Node X

- Without Colorbox FF, when I view Node A, I see a link to Node X on Field X
- When press on the link, I get a new page with Node X opens

- WIth Colorbox FF, when I view Node A, I seed a link to node A on Field X
- When press on the link, I get a black screen with a small X on the corner

Is this the normal module behaviour or is a colateral damage from the fix?

TIA

jrochate → created an issue.

jrochate → created an issue.

Well, if we take a look at eca_content the Action "Entity: set form display" is not using a hook but a setFormDisplay() from Drupal\Core\Entity\ContentEntityForm.

I've been looking at these interfaces available on core, but there is no equivalent setViewDisplay() or a similar Interface to deal.

So I think the hook is the most approximate method.

Thanks @shaal. Your suggestion solved the Ajax error problem I had on LB. Don't know if it's related, but for me worked.

jrochate → created an issue.

Worked for me. Thanks.

Missing line. Now is corrected.

I had the same problem, the previous patch solved.
But didn't react on newly created nodes, even with this #3120004: Create Notification with create state → .

So make it work, I had to keep the validation of empty because of the newly created node.

jrochate → created an issue.

Great. Thank you for sharing the planning, and the video was very helpful.

Thank you once again for all your hard work!