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"> </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.
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.
To fix facets break ajax paging (since upgrading core from 10.0 to 10.2); i upgraded Facets fro 3.0.0-beta1 to today's 3.0-dev.
Had to remove patch from here: 🐛 Disable updating the facets after each facet selection for Apply/Reset facet buttons block. Needs work as it no longer applies. Dev release does fix the issue with ajax paging however i no longer have a Views facet plugin. All views which had facet filters now show broken/missing handler.
I'll try going back to -beta1 and just using latest patch from here.
This doesn't apply to 3.x-dev version of facets.
liquidcms → created an issue.
I have a node display that has a field group (with label) wrapped around an EVA (a view meant to show up as a field on node display form). When the view returns no results i am left with:
<div class="section">
<h2>Order Information</h2>
<div class="views-element-container"></div>
</div>
Neither patch here or one from #3098550: Nested groups render on other entity forms (or when fields are inaccessible) when they shouldn't → solves the issue. I guess simply a striptags before determining emptiness is too simple?
liquidcms → created an issue.
Turns out this was getting broken by some other js library we load. I am digging in to see where the interaction is.
I think this would support what i am trying to build. I want to have one widget/star/whatever that when a user clicks it, it adds 1 to the vote total. And, if they click it again, it removes their vote.
With latest version of fivestar i get a star and an X. Not ideal but i could make that work with css. But selecting the X (to cancel) does nothing. Adding this patch changes nothing.
I also am not sure what the option for 0 stars would do or if it is required for the solution discussed here; but i don't have the option of 0 stars when configuring the field.
I agree this feature seems pretty basic and doesn't seem to be properly supported.. but, it is there. When i placed the field using a view and select to show Average vote for "Text to display under stars" it shows "Average 1 (4 votes)". The 4 votes is the total. Y could alter the summary template to remove the average part.
Sadly though, the Cancel your vote doesn't work.. different issue.
liquidcms → created an issue.
Thanks for that. Our commerce_orders view doesnt have that display so perhaps it got deleted somehow early on in the project.
And yes, assigning path to my custom order view does override the ListBuilder page.
This was originally reported for 2.17, but i just checked for 2.33 (close to latest) and:
- admin/commerce/orders as being discussed here, i am pretty sure is an entity ListBuilder page (not a view)
- admin/commerce/orders/list - as added into discussion by jsacksick, does not exist on my site.
I think making a view page to be at same url as the ListBuilder one may override the ListBuilder page. I'll test.
liquidcms → created an issue.
Not sure if this will be seen, as marked closed. Just setting this up and have a thumbsup widget which goes up on click and removes the user's vote if clicked again. My issue is i need to do a reload of the page to be able to vote a 2nd time (either undo or redo).
I could have sworn i had this working (could toggle back and forth with no page loads) last week.
liquidcms → created an issue.
liquidcms → created an issue.
All this work to change how the TZ list is generated; but still no way to alter the list?
How is this list overridden?
With the old system_time_zones() function i hacked in a patch to add an alter (which i could then use to alter the list). I assumed if this was being redone the ability to alter the list would be included; but i don't see it here. Am i correct that this class can not be overridden?
patch for code from #2
rather than try to sort out the issue with using the correct data selected in the field config; i created a separate view using the child paragraph as the base. Then using the https://www.drupal.org/project/views_field_view → module to embed this in my original view. Not ideal from a performance perspective; but works well.
I changed the title to better describe the issue here. Basically 2 issues:
1. generic entities are not supported (easily fixed with code posted above).
2. related content not supported.
For #2 i went through the render code and it is not correct for handling related content. The module's custom views field does have a setting to select which field is used to get attached entity id for the entity which has the rate widget; but this information is not used in the code. It gets the entity from the base entity of the result row. Of course views doesn't make this easy for us to get row result but it is available. I'll see if i can figure out how to properly access it. The other missing piece would be that i am not sure the view result would know the entity type that the id value is for. It may only know the row base entity (which is what the code currently is using).
My other option would be to try to arrange my setup so that the views base paragraph is the one being voted on rather than its parent; but certainly easier if this module supported related content.