🇵🇹Portugal @jrochate

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

Same here. Have you found any workaround? Thanks.

Hi.

Can you share how did you made possible to have Author field available on the Reference feeds mapping field list?

The field keywords can already be seen on feeds' mapping, but author field is not.

Thanks.

Thank you for your effort @mark_fullmer. Surely not the best option, but your patch minimizes the impact you just named.

Now there is no warning. Good.

jrochate → created an issue.

Sorry, it didn't work.

We will try to find where is this coming from, and will keep you posted. thanks Maria

jrochate → created an issue.

I'm sorry, but it's still showing the outdated drupal installation warning like before.

I have removed linkit and reinstalled (using composer require 'drupal/linkit:^6.0' to install) and I'm still having the Warning like #12 image.

Here is an example of a module that has a more recent version, starting with Drupal 10, but it is no listed as a Warning.
I think this is the desired behaviour since the Warning will tint Drupal instalations with impossible resolution (besides from updating to Drupal 10).

After cache clear and rescan modules, I'm still having the "noise" warning about an available update to a version I don't have.

The only way to avoid this is to run 6.0.x-dev, but sometimes that is not allowed due to project's policy.

jrochate → created an issue.

The feeds_ex module extends the BlankSource of Feeds module here:
feeds_ex/src/Feeds/CustomSource/JsonSource.php

When inspecting the BlankSource in Feeds module, we can see that there is no #maxlength associated: feeds/src/Feeds/CustomSource/BlankSource.php

So, the limit of the 128 chars length is imposed by Core's config entity.
Here is a discussion about it and where to go in the future #3331028 📌 Increase or remove default textfield #maxlength=128 Needs review

To circumvent this limitation, we can just add the maxlength to the BlankSource, and all the modules/source that extends it, will benefit from the change, like this one:

class JsonSource extends BlankSource {

So, here is a patch to force the #maxlength of BlankSource to be 1024.

I'm having the same problem, but I found out that Explode Tamper is not causing the problem.

The output of Explode is always a simple array, when using fields from the feed itself (like Feeds: Source or Feeds: Title).
It's the same output if with set a value a blank source like the values on the feeds fields.

So, Explode Tamper is building the array correctly.

What happens next looks like a Feeds problem, where the module encapsulates the $data result from Explode Tamper on a array, making something like this:

array:1 [▼
  0 => array:8 [▼
    0 => "https:"
    1 => ""
    2 => "xx.xxxxxx.xx"
    3 => "api"
    4 => "v1"
    5 => "cuc"
    6 => "E239"
    7 => "a-id"
  ]
]

Why Feeds is doing this is something beyond my knowledge. I have made a custom Tamper just to reduce this array dimension :(

Same here. this patch solved the fatal error.

I'm sorry, I can't help you on this, since currently I don't have a project that I can use to take some screenshots. Good luck.

Thanks. That solved the problem and is compatible now with core-recommended.

jrochate → created an issue.