🇨🇦Canada @liquidcms

We just upgraded from D9 to D10, and along the way also from 1.18 to 1.22 of this module. I now have a different issue than being reported here, but with the same title. With 1.18 this worked as expected without any patch. Which ever role was assigned perms to whichever bundle, had clone rights for that bundle only.

Now, with 1.22, non-admins do not have access to clone anything regardless if they have the perm set or not. Reverting back to 1.18 (but still in D10.4) and perms work as expected.

Found it. Just remove value.

liquidcms → created an issue.

liquidcms → created an issue.

Yes, agree with last 2 comments. This still does not work for Views.

Perhaps Views issue needs to be a different issue as people working on this seemed from the start to not get my comments above about a node "view" (mode) being different than Views.

Yes, fixed in latest -dev, but not in latest release (2.1.1.).

Marked as fixed but i am still getting this in 2.1.1, which is months after this marked as fixed. I'll try the latest -dev.

Not exactly the way this is supposed to be managed but there was a release yesterday bringing this module to 1.6.0 and it looks like this work has been committed there.

Although it does sort of work in the base theme of our theme (Barrio BS); so must be theme related.

liquidcms → created an issue.

I am using LB within Page Manager.

With D9.5.11 and version 1.0.1 of LBT i was using the -1 version of this patch and tabs was working. Not even sure i need or care about its intended use of hiding empty tabs as i dont need that anywhere (i'll test without the patch next).

After upgrading to D10.4 and still with -1 version of the patch i get no tabs (the actual tab part with the tab label) and the 1st block (tab 1) is visible. In the DOM, all tab content is there and there is nothing in the tabs div.

With -4 of the patch or no patch at all, i get nothing showing up. No tabs and no tab content.

No. Not how update module works.

also, perhaps.. i was using this in my custom module js with core version:
$.cookie('sia_cert_req_option', option);

and had to replace with:
Cookies.set('sia_cert_req_option', option);

Possibly not followed all of this but i'll list my results:
- 1 node form no paragraphs
- 2 combinations:
- field A controls B,
- field X controls Y
- all CFs set to AND

- A is a integer list field
- B is a text area field
- input mode is list of the values
- this controls visible and required
- both of these work no patches -alpha6

- X is a set of checkboxes selecting various entity references
- Y is a text area field
- only input mode that works for our use is regex: ([0-9+]) (both CFs)
- this controls visible but required is active whether condition is met or not
- same result with alpha5 or 6 with patch #59 or #64

A few different projects and at least for required fields always end up going back to custom coding this validation. But since A/B works correctly, seemed like this should work.

I guess there is now a Replicate UI module which i think replaces this module.

Hmm.. so easy to see why this broke. 1.7 had a plugin for nodes and commerce products ONLY. And the file for Products was lost in 2.x branch.

This raises a bigger question which is this the right architecture for this module? Not very extensible if you need to add a separate action for each entity type. I don't think the Entity Clone module works this way. I think the entity defn simply requires "duplicate" annotation in entity definition. Which a patch is required to add this for Products, but it is there already for many common entities, Perhaps a better approach would be to use Entity Clone a bulk operation.

liquidcms → created an issue.

@niharika.s, not sure what your comment is for. Are you just saying you see the same issue? For other modules, perhaps post the issue on those projects.

liquidcms → created an issue.

Guessing this fix didnt make it to core.

I didnt see the error in the logs but Webform sending email was being broken by the Devel Generate module with Webform 6.2.9 and Devel 5.3.1.

With Webform 6.3.0-beta1 this is fixed.

liquidcms → created an issue.

liquidcms → created an issue.

liquidcms → created an issue.

liquidcms → created an issue.

To close the loop a bit on this, i did test a different bundle with a date range field not in a paragraph. Without any patch from here it fails (sadly with no suggestion as to which field is the issue). Debugging shows it is the same issues for the date field - TZ not applied and order of date array is different (this sounds like a core bug in how original values are determined). With at least the patch from #94 (and likely other versions of patch), this field is not checked and therefore this bug messing up date fields does not impact outcome.

So i stand by my comment above; the fields are not checked recursively as would need to be done for paragraphs.

My edge case:
- i have a paragraph with both translatable and non-translatable fields
- i have a date range field with TZ enabled on the paragraph (non translatable)

I have tried a few of the patches here and currently using #128.

Regardless if "Hide non translatable fields on translation forms" is selected or not, i get "Non-translatable fields can only be changed when updating the original language.". Debugging the code and it appears a lot like the issue discussed here: 🐛 Smart Date Recurring doesn't work in non translatable field Active . Basically the date field is compared to check if has changed. For the translated value that is checked it doesnt consider TZ plus the array values of value, end_value and tz are not in the same order. This cause the check to fail (regardless if TZ is enabled or not due to ordering within the array).

I think, But not 100% sure, that the point of this fix is if fields are hidden, then they aren't checked. I have other date range fields which are not in paragraphs, and they work correctly here. So i suspect these are checked as the paragraph still has translatablke fields.. and is therefore checking ALL fields within the paragraph.

As a side note, if i make the date field translatable, i am able to save my translated node.

I tried the patch with D9.5.11. Patch applies but does not work.

Also, as mention above, this is more likely an issue for FG module than for core (unless there is a reason core is blocking this fromworking; but there wouldnt be anything in the fix that would have "field_group" in it.

Got this working, same issues with linux/windows, just composer version hell. In the end i have:

rector/rector: 1.2.10
palantirnet/drupal-rector: 0.20.0
phpstan/phpstan: 1.12.14

awesome to finally get this working :)

I used an install guide i found on the jumpstart post listed on project home. I guess this is out of date.

Did install from github project page and it seems like a much newer release. Doesnt hang now.. but spits out this:

[ERROR] Rector\Config\RectorConfig::{closure}(): Argument #1 ($containerConfigurator) must be of type
Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator, Rector\Config\RectorConfig
given, called in E:\www\next\vendor\rector\rector\src\Config\RectorConfig.php on line 199

liquidcms → created an issue.

I can confirm that this is broken in 2.0.2 and this patch fixes it (to how it was).

Export a form. Trying importing that export.

I could do this (if i can figure out how) but really don't think my patch is fixing the issue in the correct spot. This doing the query test in the parseLink method and it feels like it should be earlier on; like in checkLink().. i'll take a look but still battling other fillpdf issues that have arisen since migrating to 9.5.11.

Again, i suspect more going on here.. but here is a quick patch with the code above.

liquidcms → created an issue.

liquidcms → created an issue.

So where is this at? Still unable to disable the PayPal module?

I have D9.5.11 and RH 2.0.0-alpha5 and get this on drush updb:

 [notice] Update started: rabbit_hole_update_8106
>  [error]  Drupal\Component\Plugin\Exception\ContextException: The  context is not a valid context. in  Drupal\Core\Executable\ExecutablePluginBase->getContextDefinition() (line 184 of E:\www\Noah\next\web\core\lib\Drupal\Core\Plugin\ContextAwarePluginTrait.php).
>  [error]  The  context is not a valid context.
>  [error]  Update failed: rabbit_hole_update_8106
 [error]  Update aborted by: rabbit_hole_update_8106

The patch above does not fix this.

I tried the suggestion in #8 and it gets further but still some exceptions thrown and eventually still fails with a few of these:

 [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null: INSERT INTO `node_field_data` (`nid`, `vid`, `type`, `langcode`, `title`, `uid`, `status`, `created`, `changed`, `promote`, `sticky`, `revision_translation_affected`, `default_langcode`, `rh_action`, `rh_redirect`, `rh_redirect_response`, `rh_redirect_fallback_action`) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16); Array
> (
>     [:db_insert_placeholder_0] => 324406
>     [:db_insert_placeholder_1] => 618907
>     [:db_insert_placeholder_2] => master_events
>     [:db_insert_placeholder_3] => en
>     [:db_insert_placeholder_4] =>
>     [:db_insert_placeholder_5] => 26553
>     [:db_insert_placeholder_6] => 1
>     [:db_insert_placeholder_7] => 1694903594
>     [:db_insert_placeholder_8] => 1735239252
>     [:db_insert_placeholder_9] => 0
>     [:db_insert_placeholder_10] => 0
>     [:db_insert_placeholder_11] => 1
>     [:db_insert_placeholder_12] => 1
>     [:db_insert_placeholder_13] => bundle_default
>     [:db_insert_placeholder_14] =>
>     [:db_insert_placeholder_15] => 301
>     [:db_insert_placeholder_16] => bundle_default
> )

And the patch.

liquidcms → created an issue.

liquidcms → created an issue. See original summary → .

This is wrong, they are indexed just unclear what changed such that www.google.ca is found whereas yesterday just google was found.

So i guess, "works as designed"; but wrong.

liquidcms → created an issue.

liquidcms → created an issue.

But still main description on project home page.

Can anyone confirm what combination of code/patch works here?

I have had https://git.drupalcode.org/project/auto_entitylabel/-/merge_requests/10.... running against 3.x-dev for quite some time; but it no longer applies.

There are 2 parts to this (core):
- the form config can state any of the 3 TZ options
- the field display formatter can also select any of the 3

For my test case, both are set to fixed TZ: Toronto.

- on form i enter start time of: 8:40am
- in db i see: 12:40, America/Toronto (in other words it stores as UTC but sets TZ)
- field display on node shows as 8:40a

all good.

with your MR from other issue i tried this code:

$node = Drupal\node\Entity\Node::load(2625);
$dateService = \Drupal::service('daterange_compact.formatter');
$start = $node->field_when->value;
$end = $node->field_when->end_value;
$formatted_date = $dateService->formatDateRange($start, $end, 'date_and_time_range_with_tz', 'America/Toronto', 'en');
dpm($formatted_date);

output: From 12:41 PM (EDT) on Wednesday, September 4 to 1:41 PM (EDT) on Friday, November 1, 2024

So the TZ used in the formatter "T" placeholder is swapped in with the value from the service call; but the time is unchanged.

I see the same on a checkbox widget for a List field.

- also fails validation even when something selected

liquidcms → created an issue.

And as is always the case, after spending 3 hours trying to get this to work, 2 min after posting this i figure it out:

    if ($langcode == 'fr') {
      $language_manager = \Drupal::service('language_manager');
      $language_manager->setConfigOverrideLanguage($language_manager->getLanguage('fr'));
    }

    $formatted_date = $this->dateRangeCompactFormatter->formatDateRange($start, $end, 'date_and_time_range_with_tz', NULL, $langcode);

liquidcms → created an issue.

Marking as closed as i realized the Embed media (or other) filter converts the <drupal-media data-entity-type="media" data-entity-uuid="e35b7fd8-4e8b-4b50-987e-327e376b31a6">&nbsp;</drupal-media> tag to an img tag before this gets a chance to act. Re-ordering the filter higher up fixes the issue.

liquidcms → created an issue.

I also want to hide/disable the moderation state field on the edit form as i only want editors to access state changes through the moderation control block.

setting either:

$form["moderation_state"]["widget"][0]["state"]['#disabled'] = true;
or
$form["moderation_state"]["widget"][0]["state"]['#access'] = true;

attempts to leave the Published state as Published even though workflow want to force it to Draft. And in the case of #disabled, where i can still see the selection, it is selecting Draft but in all cases i get error saying Live to Live is not a valid transition (which it isn't).

I would think either hidden or disabled should still allow workflow default transitions to occur.

$message translation?

Sorry Liam, Spent 30 min trying to figure out making an MR and gave up. Branching off default is 5.0 but it is old code. Branching off 5.1 and there is no code. And there is no branch for 5.2.

No idea how to reproduce. I assume since everyone doesnt have this issue there must be something corrupted in the content of these that gets in the way of this working. These are content; this is bound to happen. Should be config entities.

Patch attached. I really should figure out gitlab/drupal MRs (I make github PRs every day).

liquidcms → created an issue.

I agree entirely that this would be much cleaner if fillpdf forms with field definitions were config entities.

Patch doesnt apply to 5.1.1. but adding the same disableCache() call at top of the same form method does fix my issue.

I suddenly have the same issue with 5.1.1. Haven't tried patch here. Trying that now.

I tried the patch from #25 against 10.2. Patch applies but does not work.

In my case i was trying to remove an option but am blocked from saving the form. But this is just a form validation. I removed the value from the config file and re-imported. This worked for me.

TCPDF does generate images but PDF is not very representative of the html - img is full size, styles are off. Inline style in tiwg teample have no impact when using tcpdf.

But... i am not able to disable SSL verification on our (Kubernetes) server or view pdf just spins forever. With verification enabled then same result as reported here - PDFs are created but images (and i think CSS) are not included.

I think i suggested no interest as there was already an issue posted about this, that i think had been closed.. but maybe I am mixing it up with something else.

And not sure how to reproduce. I suspect it is from config which exists in db that there is no .yml in sync folder for. Which, typically with cim, would simply be removed; but i think with config ignore, it throws an error. With the module disabled i think cim works as expected.

Would it be unreasonable to think of that as an added feature? I.e. "add tag definition by path" either through ui or a hook. Would think a shame to lose all the advanced tag definition provided by this module to go with a simple core hook to modify these in code.

Ahh.. good to know. Thanks for the reply.

liquidcms → created an issue.

Figured out my issue. Just needed to disable SSL verification in Entity Pring SSL config

I have issues including images in my PDFs as well. Realized it works when site is run as http:// but not when run as https://.

Using DomPDF.

changing like 184 of the Event Sub to this:

if ($ignored === TRUE && !empty($destination_data)) {

fixes this. I'll submit a patch even though it seems that project maintainer may not be interested in fixing this.

liquidcms → created an issue.

and now, magically, button gives Access Denied at: en/admin/structure/types/manage/article/display/translate

switched to patch from #75 and now i see a Translate Layout button (at least now i know what the expected ui is); but it throws this error:

Error: Call to a member function get() on null in Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage->getTranslatedComponentConfiguration() (line 481 of E:\www\SSC\d10.0\web\core\modules\layout_builder\src\Plugin\SectionStorage\DefaultsSectionStorage.php).

Sorry, lost in where this is at. I swear (back in D9 at some point) i had tabs when in LB and one of those was to "Translate layout"; but now (D10.2.2.) NO tabs.

I have a vanilla D10.2.2 site with these patches:
- https://www.drupal.org/files/issues/2024-06-28/3044993-79.patch →
- https://www.drupal.org/files/issues/2024-03-15/2946333-327_Revised_patch... →

Additionally:
- Article type set to be translatable
- Basic block set to be translatable
- Article default view mode set to use LB (for all nodes)
- Add inline basic block using LB

There is no apparent UI to access translation of this. I have tried a couple urls as mentioned above:
en/admin/structure/types/manage/article/display/translate - access denied
en/admin/structure/types/manage/article/display/default/translate - throws:

Error: Call to undefined method Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage::getTranslatedComponentConfiguration() in Drupal\layout_builder\ConfigTranslation\LayoutEntityDisplayMapper->hasTranslatable() (line 55 of E:\www\SSC\d10.0\web\core\modules\layout_builder\src\ConfigTranslation\LayoutEntityDisplayMapper.php).

Any hints?

from my post: " entity type's layout" - so not layout overrides, so i guess this module is not my issue.

thanks.

Might be useful to include a comparison of these. Is there a reason why i want to go to the trouble of installing any of these over just using the built in Dompdf?

liquidcms → created an issue.

@solideogloria, from what you describe in #6, that is not auto login. Auto login would not go to that page, it would just connect to your Auth provider. What do you see with auto login enabled?

Also, the name of the option (force replace) does sound like what you've described, which is not auto login.

We have done up a patch but would conflict with the auto login patch, so we've merged both functions into 1 patch. Just need to do some testing and will post here.

I think the logic behind this is incorrect. As the title suggests, there should be an option to "disable the use of showcore". This isn't the same as forcing the login page with the OIC button. It should simply stop showcore in the url from doing anything.

It is difficult to develop against possible future enhancements; but I'd say it is safe to assume the Autologin feature ✨ Autologin when one client enabled Needs work will eventually be merged; and this patch does not take that into account. The admin UI for this shouldn't be "force replace" or anything to do with those options; it should simply be a separate checkbox for "Disable showcore" (or even better, it should be "Enable showcore" and have this security hole disabled by default).

With that feature disabled and autologin enabled; then going to user/login?anything-including-showcore would simply attempt to access whichever auth client is being used.

Patch on the way.

Sadly still no help here on how to have a mix of translatable and non-translatable config. ChatGPT suggests the fields need the schema parameter of translatable: true/false; but this does not work (D10.2).

re: #5.. yes, you could have it optional if Key is installed but this isnt the direction most other API modules (openid, s3fs, azure key vault, etc) are taking. They are simply making Key a dependency (what's the harm in that?). If you want to stick with simply storing smtp password in config, then you can add a config "key" and still do that.

+1 for the patch to add Key support.

liquidcms → created an issue.

Patch to remove the code above.

git commit -m 'Issue #3456863 by liquidcms: Layout Builder ST not listed in modules list' --author="Peter Lindstrom <24279-liquidcms@users.noreply.drupalcode.org>"

Patch attached.

liquidcms → created an issue.

Tried on a more vanilla site (no WxT modules enabled at set up) and it works as expected. Enabling WxT Layout breaks it.

liquidcms → created an issue.

Patch from #41 on -beta1 rather than latest -dev fixes pager as well as facet exposed filters. Still doesn't apply with 🐛 Disable updating the facets after each facet selection for Apply/Reset facet buttons block. Needs work but i'll redo that patch.