🇵🇹Portugal @jrochate

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!

jrochate → created an issue.

Well, after this time I found out that my previous response was about node entities and not user entity.

The OP explained his problem about user entity, and I have come to the same conclusion:

- the modify form mode works when dealing with node, but is doesn't work with user. The default for is always chosen, no matter what configuration and permissions are being set.

Using ?display=form_mode_name works, but there should be the possibility of having the default configured on module's config form.

This can be solved if you go to body field (or other text formatted field) Aggregation settings and check the box Format under Group columns (additional).

After this, the HTML is rendered even with views aggregation activated.

Changing the aggregation settings from Value to Entity ID, like proposed by OP can have side effects on certain query conditions.

here is a possible change.

now, go to Mailer Policy, and add a Policy with:
- Type: Workflow Notificatipns
- Sub-type: the machine name of a notification
- Set the From address and other options at will

jrochate → created an issue.

Using this versions:
- Drupal 10.1.7
- Quick Node Clone 1.16
- Layout Paragraphs 2.0.4
- Paragraphs 1.16

I have patched with #3183249 but still didn't get paragraphs do be clone inside the LP paragraph.
When the page's #14 patch, conclude that they can't be applied simultaneously.

But....

When applying ONLY this page's #14 patch, the clone works like expected.

So, thanks to @DamienMcKenna and @Anybody. This could be merged.

Thanks. That worked for m e.

Yep. It's all fine now. Thank you for your immediate response. :)

jrochate → created an issue.

Wow! Thanks Joshua, for your kind help and clear explanation.

I totally understand the code. is very clean and concise. Will give it a try.

Meanwhile I'm still reading more about your ABAC approach and see if I could keep it strict, without replicating PbT using the above code.

Once again, thank you very much about the work you've been doing here. Awesome!

Thanks @josh.fabean.

Same here, the patch solved it.

jrochate → created an issue.

jrochate → created an issue.

jrochate → created an issue.

Another situation solved by #11 and just like @aharown07 #15. Worked on some CT others not.

Unticked the HTML filter on the title field (and other text fields) and now it comes up on searches.

You can use version 1.2, as it is compatible with 8.8

Check here and install as usual:

https://www.drupal.org/project/xmlsitemap/releases/8.x-1.2 →

I got this error also. Line 206.

Nevertheless, the search page is created.

Same here:

the medias image field's names are customised.

So, I get this on install:

Unable to install Ckeditor Media Resize due to unmet dependencies: core.entity_view_display.media.image.cke_media_resize_large (field.field.media.image.field_media_image, media.type.image)

This is still a nice to have feature on todays feeds state.

Only realised that after having content permanently deleted when emptying items from an import feed :)

I had no problems with a JSON export.
A new option appeared below Image Style with Format: Rendered or Plain URL

Thanks. very handy.

I don't have standard media machine names, and the latest path WSODs.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "media_base_image" plugin does not exist. Valid plugin IDs for Drupal\feeds\Plugin\Type\FeedsPluginManager are: file, datetime, number, media_file, uri, feeds_item, config_entity_reference, integer, temporary_target, daterange, email, timestamp, password, book, image, media_image, user_role, link, text, boolean, telephone, langcode, entity_reference, path, string, geofield_feeds_target, paragraphs in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53

and also

Error: Class "Drupal\feeds\Feeds\Target\MediaFile" not found in Drupal\feeds\Entity\FeedType->getMappingTargets() (line 305 of /var/www/clients/client1/web39/web/repos/ccmar/web/modules/contrib/feeds/src/Entity/FeedType.php)

it looks like we must use standard profile installation because the fields are hardcoded.

Create a new issue with your request, as your question has nothing related to the original post.

jrochate → created an issue.

jrochate → created an issue.

Same here. When adding a new node, press Save and Add Another, and the user is redirected to home (the node is saved fine), instead of keeping the user on the new node form.

Bump to 6.0.2

Yet another bump to latest