tonka67 → created an issue.
Thanks @jurgenhaas. I'll try to find some time to play around with it in the next week or so.
tonka67 → created an issue.
Works for me. Thanks to both of you for resolving this.
rerolled for the post 8.x-1.0-rc3 dev version on D10. This applies, but it also pulling the following error:
Deprecated function: Creation of dynamic property Drupal\commerce_recurring\Form\BillingScheduleForm::$notificationManager is deprecated in Drupal\commerce_recurring\Form\BillingScheduleForm->__construct() (line 56 of /code/web/modules/contrib/commerce_recurring/src/Form/BillingScheduleForm.php)
Ah, that's good news. I don't think I have bandwidth to test this weekend but I'll get it into my schedule as soon as I can, unless someone else gets to it first.
Has any progress made on this issue? This upgrade renders my entire site unusable - and I have too many complex models with flag elements to rebuild them all from scratch.
@gilmord it took me longer than expected to loop back around to this.
On testing I can get the Title field to work perfectly, but the body field, which has a ckeditor attached to it, does not register the ajax at all.
Are long, formatted text fields set up differently?
Reopening this, in hopes there's enough support to bring epub export functionality into Drupal10+.
Thanks for reopening this. Looks like there's been a reversion in DraggableViews 2.1.4. I'm pulling the following error again:
Warning: Undefined property: Drupal\views\ResultRow::$nid in Drupal\draggableviews\DraggableViews->getIndex() (line 44 of /code/web/modules/contrib/draggableviews/src/DraggableViews.php)
Patch #32 fixes the immediate problem but throws a sitewide error for me:
[Violation] Added non-passive event listener to a scroll-blocking event. Consider marking event handler as 'passive' to make the page more responsive. See
[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952
DraggableViews 2.1.4
D 10.3.2
PHP 8.2.21
Aaaand, it's back. Again, this is on a node page, not the front page. I was building the page directly from the node content. When I rebuilt it in Layout with view blocks and a contextual filter instead, the error cleared. Since this is a routing problem, I'm guessing it has something to do with passing the parameter from the URL to pull the correct content directly from the node.
I tried stripping out the EVA and anything other non-standard fields. Same issue.
For what it's worth, I'm also on Pantheon.
tonka67 → created an issue.
Hmm, so the error disappeared in production. I cloned production back into dev (I was overdue for a cleanup reset anyway), and it cleared. I'm going to assume it persisted due to a legacy dev experiment that no longer exists.
But, yes, the issue did affect pages for me other than the home page. I also had a view last week that suddenly failed and triggered the same warning.
I'll keep an eye on things and will post if I see it again.
Yes, I've got one content type set to display author bio pages. It's a simple node with the following field types:
image, markup, body (text formatted, long, with summmary), 2 text (plain), and link field
It does have a views EVA footer, though, so I'm looking now to see if that might be the cause.
I just upgraded to 10.3.2 and still see this issue. My site is English, not bilingual. It seems to affect one set of content page types, but not others, but they're identical except for the block layout.
tonka67 → created an issue.
I'm also getting the Uncaught TypeError notice, but my icons all seem to be working for all roles.
Yes, I think those are the same thing. Not sure how I missed them in my support search, but it looks like I'm not the only one seeing it in the 10.3 upgrade.
tonka67 → created an issue.
No, just double checking to make sure the patch is now obsolete.
Looks like this was committed as of June 1, 2024. Could someone confirm?
tonka67 → created an issue.
tonka67 → created an issue.
It looks like this feature was committed, but I'm at a loss as to how to use it.
I see that two new fields appear in the views field settings:
- Fields that trigger an ajax submit when they change (autosave)
- Event that will trigger an ajax submit for the fields above
Adding anything at all to the first field causes the update button to hide, but I can't get the field itself to update. What is the correct syntax?
Does something else need to be configured, or is there an additional missing patch? Should the view's Ajax be on or off? Some direction would be appreciated.
Took me a while to circle back, but #83 works great. Thanks so much.
Thanks. It's not an urgent need, so I'll make due for now. But I do have you on my emergency contact list, should anything else go down.
Yes, the token was empty, but it still deleted the array. I'm still not clear how this can be the case.
But, as you say, I have a working model, so I'll have to experiment some other time.
Hmm, so now I'm confused because it was deleting all the items in the Views array.
OK, so running actions on a Views Query requires the entity ID to be placed in the view. Just restating this for future folk who might run into the problem.
tonka67 → created an issue.
Thanks @mferanda. #2 🐛 D10 Symphony Encoder fail Active works a dream.
I'm back to the errors I reported in #80 ✨ Add Export to Word Support Needs review .
Has anyone found a solution yet?
Ok, finally found some time to do some testing.
TEST 1:
Create content: test1
View:
Content type: test
Fields: ID, test field
Update model to:
Event: create test content
Load: view query
Load: entity from view
Message: show view [token:node:id]
Created content: test2
Expected message to show id of content test1
Results: Correct
--------------
Test 2:
Update model:
Added Delete Loaded Entity
Created content: test3
Expected content test1 to be deleted
Results: correct
>>>obeys offset
--------------
Test 3:
Update Model:
Remove Load Entity
Set Delete on the View
Set Message to show View token
created content: test4
Results: deleted all items in list except test4
Message shows deleted item
>>obeys offset
----------
Test 4:
Disabled model
Added content: test5, test6, test7
Reenabled model
Added content: test8
Results: deleted all items in list except text8
Message shows all items in View queue, obeys offset
------------
Test 5:
Reloaded model posted earlier. Model is:
Event: create content Test
Load: View Query
Delete Entity: Loaded View Token
Message
Added content: test 9
Results: deleted test 9, left remaining content
Message: token is empty
-----------------------------------------------
So, this is weird because Test 3 and Test 5 should have had the same results, since the models are substantially the same. Am uploading the Test 3 model here for comparison.
tonka67 → created an issue.
I've run into a new problem with this solution. For reasons I don't understand, it's causing all my layout builder pages to throw an Ajax loadjs error after login. This seems to be a conflict with Big Pipe, because the issue goes away when I remove either big pipe or delete the ECA modal and comes back when both are installed together.
The console error looks like this:
An error occurred during the execution of the Ajax response: LoadJS
(anonymous) @ js_[hash].js?scope=footer&delta=0&language=en&theme=mytheme&include=[hash]:58
Promise.catch (async)
Drupal.Ajax.success @ js_[hash].js?scope=footer&delta=0&language=en&theme=mytheme&include=[hash]:58
processReplacement @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
checkMutationAndProcess @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
(anonymous) @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
processMutations @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
I'm seeing the behavior in both chrome and firefox. Attached a basic modal example for review.
I'm still having this problem on 10.2.2. but my console errors (anonymized) read:
An error occurred during the execution of the Ajax response: LoadJS
(anonymous) @ js_[hash].js?scope=footer&delta=0&language=en&theme=mytheme&include=[hash]:58
Promise.catch (async)
Drupal.Ajax.success @ js_[hash].js?scope=footer&delta=0&language=en&theme=mytheme&include=[hash]:58
processReplacement @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
checkMutationAndProcess @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
(anonymous) @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
processMutations @ js_[hash].js?scope=footer&delta=2&language=en&theme=mytheme&include=[hash]:67
For what it's worth, the problem only seems to occur on pages that use Layout Builder. It's not a problem when the page was generated in Views.
Disabling Big Pipe clears the problem and it comes back when I re-enable it.
tonka67 → created an issue.
Kindly disregard my previous question. I was overthinking. A regular token calling [current-page:url:unaliased:path] did the trick.
Any thoughts on how one might restrict results by limiting the route to a specific node?
I've tried:
Action triggered by
event = RESPONSE CREATED,
condit = ROUTE MATCH compared to "entity.node.canonical"
Token: Load Route Parameter = "/node/{node}"
condition = Token value IS SpecifiedNodeID
Redirect
But the token isn't loading anything. I've tried every variation of {node}/{node_id}, variations on node/preview/{node_preview}/{view_mode_id} using canonical, and everything else I can extrapolate from the node.routing.yml, but nothing works. Is this the right way to attach a routing parameter here?
I came up with an if/else conditional workaround that checked whether or not the item was new or preexisting, and set the delete on preexisting items only.
If I can carve a few minutes out of my weekend, I'll try your suggestions and will post my results, for future reference.
Apologies for the typos. Long dev day.
I set up a new test run using nodes to keep things simple, as follows:
Node Type: Test
Added field: field_test
Created View
Type: Content > Test
added field: field_test
set pager show all, offset 1
no relationships, filters or conditional fields to keep things clean
Created Model
as above. Export file attached.
enabled model
Test run:
1) added Test content
Results: content deleted
not expected
2) disabled model
added test content
content created as expected
reenabled model
added 2nd test content
new content created as expected
previous content deleted as expected
tonka67 → created an issue.
This might be related:
I just added an existing field to a new contact form. A short while later, I decided there was a better way to do things, so I tried to delete the field. I also got a warning list of ECA models that would be deleted, but these models relate to other forms that use the same field. I wasn't deleting the field from all instances, just the one.
tonka67 → created an issue.
I retried Patch #72 after upgrading to Drupal 10.2.2. Now I'm down to 1 error:
TypeError: Cannot access offset of type string on string in Drupal\Component\Utility\NestedArray::setValue() (line 155 of /code/web/core/lib/Drupal/Component/Utility/NestedArray.php).
Looking at the console inspector, I also found the following (which does not exist without the patch):
[DOM] Found 2 elements with non-unique id #edit-submit: (More info: https://goo.gl/9p2vKq) <input data-drupal-selector="edit-submit" type="submit" id="edit-submit" name="op" value="Save configuration" class="button button--primary js-form-submit form-submit">
Continuing to dig around and experiment. I now believe the problem to be something to do with file and/or processing size - if I set no relationships or filters, I can set about 30 long text items in the doc. Anything more gives me a memory warning when I try to open the doc file:
Word experienced an error trying to open the file. Try these suggestions.
* Check the file permissions for the document or drive
* Make sure there is sufficient free memory and disk space
* Open the file with the Text Recovery converter
If I include more relationships and filters, I have to reduce the allowable items to 10.
Question - is this limitation coming from the module or from my server settings? I need to be able to download considerably larger docs. Right now, I seem to be limited to around 15-16kb doc, 2 pages and/or a few hundred words.
Turned out the media details needs to be wrapped in quotation marks, so the correct format is:
global-styling:
css:
theme:
css/custom-style.css: {}
css/custom-style-mobile.css: { media: "all and (max-width: 1000px)" }
https://fonts.googleapis.com/css2?family=Poppins: { type: external }
js:
js/customjs.js: {}
I'm quite sure the error is coming either from a problem with my libraries syntax or I'm missing something (maybe it needs to be called separately in the info.yml?). I've looked everywhere and can't find instructions for D8/9/10.
The solution I referred to wanted to call stylesheets by breakpoint name, not by screen size. The part at the top with the screen and device sizes he quotes as the standard should work, as far as I can see. The hackish bit isn't relevant.
It's a large site and keeping mobile css in separate sheets by breakpoint makes it load faster and is easier to manage.
After some more digging around, it seems that the issue has to do with views relationships, which causes both permission and display issues in production. Neither of the fields in question had relationship links attached to them, but other fields did. Removing all the relationships restored the field display for both.
tonka67 → created an issue.
I'm working with Patch #72 on entity_print:2.x-dev, Drupal 10.2.1 and PHP 8.1.26.
After installing phpoffice/phpword:^1.0 per installation prompts, I set the Word engine, but threw a "The website encountered an unexpected error. Try again later." error on the config page that would not clear. I uninstalled both Entity Print and Entity Print Views, then reinstalled. Now I can't set the word engine at all - when I click save, it throws the same error on the page, but while I can now refresh, none of the changes are saved.
This produces similar errors to the previous folk, with some differences:
TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 263 of /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Warning: Array to string conversion in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 281 of /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
The submitted value 1 in the Word Document element is not allowed.
tonka67 → created an issue.
Patch #19 🐛 Fix incompatibility with Views Enity Form Field Needs work applied clean on 2.1.3, but changes don't save. I get an "No Action option selected" page error instead.
#20 🐛 Fix incompatibility with Views Enity Form Field Needs work failed to apply.
It was working in my FF dev and test environments. Not in production. I tested in two different systems - on Windows10, the other Windows11.
I cloned my live site back into the test environment a couple days ago so they should be identical.
Sadly, no change with
var btnId5 = this.dataset.id;
It still works in Chrome and Edge. FF still works once then freezes up.
For what it's worth, I don't get an empty value for btnId5. My set up looks like this:
<p data-id="togglethis">change</p></span>
<div class="hidecontenttogglethis hidden"><div>hidden content here</div></div>
The code creates links which, when clicked, toggle a div somewhere on the page. When I say they go dead, the links stop responding at all, and nothing happens in the DOM or anywhere. When the links work, the clicks respond, I can see the action taking place in the inspector, and the console.log() validates from my jquery code. Then they stop after one or two clicks. No response, no console log, nothing.
I agree it's not a caching issue. I tried in incognito mode with the same results.
It appears to be working once or twice and the console validates accordingly. Then the links go dead and the console remains blank. If I input console.log() directly into the browser console, it still validates. Other jQuery code on the page works fine, so I'm thinking it may have something to do with the Once call and/or a caching problem?
tonka67 → created an issue.
That still throws:
Error: Call to undefined function drupal_get_path() in coffee_zymphonies_theme_get_slider_content() (line 176 of /code/web/themes/contrib/coffee_zymphonies_theme/coffee_zymphonies_theme.theme).
Looking at the Freelance patch, instead of this:
@@ -128,7 +128,7 @@ function coffee_zymphonies_theme_preprocess_page(&$variables) {
//To get the current URL
$current_url = \Drupal::request()->getRequestUri();
$current_path = explode("/", $current_url);
should it be:
$current_url = \Drupal::request()->getRequestUri();
// $current_path = explode("/", $current_url);
$current_path = parse_url($current_url);
The following files also have a dependency on classy theme, which is removed from Drupal10 core.
Most call {{ attach_library('classy/file') }}
, but I haven't checked them all:
web/themes/contrib/coffee_zymphonies_theme/templates/field/file-link.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/content/node.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/content/search-result.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/content/comment.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/dataset/forums.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/navigation/book-navigation.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/content-edit/image-widget.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/content-edit/file-managed-file.html.twig
web/themes/contrib/coffee_zymphonies_theme/templates/misc/status-messages.html.twig
tonka67 → created an issue.
Thanks, @Swathi257. That does the trick.
Same issue, affecting 2 custom modules and my 2 child themes, on pantheon.
Bringing my secondary issue from eca commerce → over.
@jurgenhaas Could you provide me with a bit more information?
In my case, I'm using eca_commerce to trigger when an order is completed. My model then adds the user to the pre-configured paid member role and removes them from two lower level pre-configured roles. I'm assuming the roles options are the checkboxes causing the problem.
What's the best workaround for this use case?
You say "As a workaround, for now the eca commerce conditions should fall back to single value checkbox for now" (from my previous issue).
Does this mean it will work if I split the 3 changes into separate modules, or do you mean it will only work with fields that have a single boolean checkbox option?
I'm still testing functionality and it looks like the system is picking up the UID even though it's not showing in the contact message list. However, not being able to cross-check ids makes it difficult to know for sure.
There was some old work done to help facilitate contact message manipulation in views here: https://www.drupal.org/project/contact_storage/issues/3052300 ✨ Add views relationship for user that submitted the contact form Active , but nothing since.
So, this comes down to the question: why does the UID display cleanly in my docker container but not in my live site environment, everything else being equal? I've checked the databases, I've checked the list display views on both sites. I don't see how the server environment could be affecting the display.
tonka67 → created an issue.
That cleared the error message, but left me with this:
Warning: Array to string conversion in Drupal\eca_modeller_bpmn\ModellerBpmnBase->prepareConfigFields() (line 776 of /code/web/modules/contrib/eca/modules/modeller_bpmn/src/ModellerBpmnBase.php)
#0 /code/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'Array to string...', '/code/web/modul...', 776)
#1 /code/web/modules/contrib/eca/modules/modeller_bpmn/src/ModellerBpmnBase.php(776): _drupal_error_handler(2, 'Array to string...', '/code/web/modul...', 776)
#2 /code/web/modules/contrib/eca/modules/modeller_bpmn/src/ModellerBpmnBase.php(594): Drupal\eca_modeller_bpmn\ModellerBpmnBase->prepareConfigFields(Array)
#3 /code/web/modules/contrib/eca/modules/modeller_bpmn/src/ModellerBpmnBase.php(544): Drupal\eca_modeller_bpmn\ModellerBpmnBase->properties(Object(Drupal\eca_commerce\Plugin\ECA\Condition\Commerce), 'condition', 'bpmn:SequenceFl...', Array)
#4 /code/web/modules/contrib/bpmn_io/src/Plugin/ECA/Modeller/BpmnIo.php(76): Drupal\eca_modeller_bpmn\ModellerBpmnBase->getTemplates()
#5 /code/web/modules/contrib/eca/modules/ui/src/Controller/EcaController.php(206): Drupal\bpmn_io\Plugin\ECA\Modeller\BpmnIo->edit()
#6 [internal function]: Drupal\eca_ui\Controller\EcaController->edit('process_kkjxbdj')
#7 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#8 /code/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#9 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#10 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#11 /code/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#12 /code/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#13 /code/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /code/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /code/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /code/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /code/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /code/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /code/web/core/lib/Drupal/Core/DrupalKernel.php(718): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /code/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#21 {main}
.
I'm seeing this too - came up during migration. I disabled the model and reran the import - came up clear.
I'm still experiencing this issue with 8.x-1.0-rc1 on D9.5.10.
It appears the above patches were committed. I'm at a loss trying to figure out what could be retriggering it.
Thank you. I'm happy to assist with testing.
I'm not looking to affect visibility. Rather, I have one field whose display values are dependent on another. For examples:
Field 1 (Categories): Cars / Apples /Horses
Field 2 (Items): Honda / Toyota / Granny Smith /Fuji / Arabian / Pony
When Field 1 is set to a category, only the items relating to that category are displayed.
Business Rules does this, but it's already several years old and doesn't work properly. Dependent fields only works with select fields, which isn't useful.
I was hoping there might be some way to accomplish this in ECA instead. For example, when Field 1 is changed, send the new value as an argument to the entity reference field in Field 2, then refresh the view to get the updated value?
tonka67 → created an issue.
tonka67 → created an issue.
Alternately, would it make sense to wrap the markup in a <div> and class and then just hide the ones I don't want via CSS?
I'd like to keep the updated notice for some forms, but remove it for others. For example, if the user is updating personal data, the updated notice is helpful. In some cases, I have forms designed as productivity tools, so changing values in something like a calculator with a dependent field attached shouldn't declare the change.
Instead of writing the hook on a form-by-form ID basis, wouldn't it make more sense to set a class to the form instances I want to override?
That's fantastic, thank you.
Is there a way to write the hook so I can turn off the message selectively? Perhaps on a class basis?
tonka67 → created an issue.
I had thought it was a global issue, but further investigation suggests it's coming from the editablefields module when used with views. I'll do some more digging.
tonka67 → created an issue.
tonka67 → created an issue.
tonka67 → created an issue.
tonka67 → created an issue.
Apparently, the entire system main content block was renamed and duplicated. It was easily removed from the block layout page, once I found it.
Has any further work been done on this issue? I have a batch of user views that need a relationship set to the contact message user ID.
I can't find any other discussion on this problem elsewhere and would prefer a stable solution, if there is one.
@TwoD Thanks, that helps. I'll keep tweaking it. Meanwhile, I've had some success by-passing the problem altogether by re-architecting my entityreferences.
@TwoD (#347) - can you specify which files had the extra whitespaces in them? I'm wondering if I missed them, and they might be the reason I'm not seeing results.
Tried applying patches 195 and 332. No errors, but neither one worked. Is a PHP 5.5 workaround still in the works? I just updated to 7.51 with PHP 5.5.24.