This may be more a future option, but it's far more efficient to upload a file and then reference the file rather than send it as filedata. base64-encoded content is treated like raw input. The model must process the file contents as tokens which can get pretty expensive. Also, not very scalable for large files and can even get truncated. I believe it also counts against your context window..
I'd be in favor of looking at how we could use the file upload + thread to enhance this
Adding the +1 for visibility here as it's getting far more common to use S3-type storage here
Everything looks fine, confirmed I don't get the circular referencing as well. Small comment about calling out the change between core and override.
Fixed!
b_sharpe → made their first commit to this issue’s fork.
Ok, had to update the fork and recreate the entire thing here as build conflicts were hooped. Set to 3.0.x and added in the proper schema updates
Adding patch file against 3.0.1/x for composer.
b_sharpe → changed the visibility of the branch 3449206-allow-a-default to hidden.
b_sharpe → changed the visibility of the branch 8.x-2.x to hidden.
b_sharpe → changed the visibility of the branch 3.x to hidden.
b_sharpe → changed the visibility of the branch 3449206-default-single to hidden.
b_sharpe → changed the visibility of the branch 3.0.x to hidden.
@gareth.poole added, sorry for the delay
Just leaving a note here in case someone else ran into my problem after updating to 10.4+, this breaks functionality in which an ajax response might not be a valid child of a div whereas with jquery it was working. For example if you were returning a table row into an already existing table a <tr> is not a valid child of a div so it will be stripped from the response.
I don't necessarily think this warrants a bug ticket as it's probably the right way to go in the future, but it caused me some headache so felt I should leave a note here.
@osopolar, the intention is to remove D10 support which will allow removing this property as in D11 we can use isSyncing() per 📌 Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing Fixed
If you're on D10, just stick with 2.0.0 for now if you don't need this property.
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
@alieffring This property technically will be going away with dropping D10 support; however, I would think this is more something you should be aware could change from any contrib module that alters a base definition (albeit this one sucks as it went from one property to multiple which JSON API auto changes to an array)
If you're already on D11, you can likely just comment out/remove this hook: git.drupalcode.org/project/field_defaults/-/blob/2.1.x/field_defaults.module?ref_type=heads#L16
I've flagged 2.0.0 as supported in the meantime so D10 people have an option to stay.
Much cleaner using NestedArray::getValue().
Please review.
b_sharpe → changed the visibility of the branch 3457701-getfontfamily-ajax-error to hidden.
Nevermind, found it, but I think this is wayyyy over architecting. Let me try something new here.
I'm having a hard time recreating this. I've tried inside a paragraph on a block inside Layout builder and not seeing any errors. Can you provide a step by step?
Fixed along with phpcs fixes. Thanks all.
b_sharpe → made their first commit to this issue’s fork.
Makes sense, thanks!
b_sharpe → made their first commit to this issue’s fork.
Fixed.
lets get this in
b_sharpe → created an issue.
Token support most definitely could be added; however, I don't see how context of an entity could be used so it would only support global tokens like [site:name]
@dieterholvoet I just tested on a fresh D11 and while you are correct the DB entry does not exist (I'm not sure when this changed or is dependent on env setup), the session cookie does exist.
The problem isn't that the form itself is uncached, but that with the session cookie all subsequent requests are uncachable by page cache until that cookie is deleted or expired. For a lot of large sites, this usually means bypassing CDN's as well as extra strain on the server while it serves dynamic page cache to anonymous users that would have otherwise been page cached without the cookie.
Hopefully that clears things up.
Ha, was actually just coincidence, I needed this to fix a prod instance today.
I would normally agree about a new test over editing; however, in this case the edit made more sense as the old test is for testing both AND/OR (testMultipleConditions()) and would have caught this issue in the first place had there been more than one context so I figured the edit made more sense.
Can we get this committed?
Moved to MR, edited existing test to use two different contexts so that the AND/OR conditions are properly evaluated / tested.
Test fails without patch: https://git.drupalcode.org/issue/block_visibility_groups-3503194/-/jobs/...
Test passes with patch: https://git.drupalcode.org/issue/block_visibility_groups-3503194/-/jobs/...
b_sharpe → made their first commit to this issue’s fork.
b_sharpe → created an issue.
b_sharpe → created an issue.
Thanks!
b_sharpe → created an issue.
Thanks
MR moved over to core, looks like some cspell and phpstan failures need addressing.
b_sharpe → changed the visibility of the branch 3355485-recipes-unpack to hidden.
Yup, that was it, it wasn't checking for proper values of checkboxes for languages. Try the MR and let me know if works for you as well.
Thank you, it appears this is related to translations which is why I couldn't recreate it. I will take a look
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
hestenet → credited b_sharpe → .
I can't seem to reproduce this. If I don't select override then nothing is triggered. What drupal core version are you on?
Just a new version for 3.7, also adds in a fix for #25 to pass the scheme for stream_flush()
Added unit test to prove new functionality.
Attaching patch simply for composer.
b_sharpe → made their first commit to this issue’s fork.
My bad, I credited you in the commit which used to do on here as well but has changed since the gitlab change I guess. Updated :)
I believe this just needs a Documentation update. The "Parent" here is technically just the output, and should be included when combining views.
Thanks!
b_sharpe → made their first commit to this issue’s fork.
Merging to move forward the broken tests.
Hard to tell without knowing your setup, but the main problem I can see is you're trying to utilize fields as output, when combining views you MUST use only "Rendered Entity" for the field output
Moved to MR, still needs tests.
b_sharpe → changed the visibility of the branch 3257811-tmp-path to hidden.
Removed Destination, adding patch for composer.
b_sharpe → changed the visibility of the branch 3492997-remove-destination to hidden.
b_sharpe → created an issue.
My guess is you're going to have problems with all sorts of queries if you're trying to join/union between separate DB's.
Drupal technically can work this way, but only if the DB's are on the same server. Most managed hosting these days the DB server is different between DB's which means join/union is not natively supported without FEDERATED storage.
Open to MR's here to solve, but just thought I'd point that out
b_sharpe → created an issue.
Are you just dealing with 🐛 Cannot have div tags inside columns in CKEditor 5 Active ? This was fixed in 2.1.x
b_sharpe → created an issue. See original summary → .
Same
MR for review, adding a todo for D11 change. Also added 📌 Fix Tests, Add Preserve Changed Test Active to test this in the future
b_sharpe → created an issue.
It appears the API here has changed in core. Also as of drupal 11, we can use #2329253.
b_sharpe → made their first commit to this issue’s fork.
Updated project page, thanks both!
Added https://github.com/pfrenssen/coder/issues/238, please review.
Code looks good and works, added comment as I'm not sure if this needs a doc update specific for config actions and/or recipes?
Looks good, test failure was unrelated and passing after rerun 👍
Nice! Tested and working as designed. RTBC
Looks good
Up for discussion, but if I'm wanting to clone an existing config and it doesn't exist, I'd expect an error here rather than just not cloning as this could affect further actions.
Removed my comment as I think base plugins make sense to be named this way as in `entity_create` and have derivatives be camel case. Everything looks great! RTBC
Everything looks good, I'm sure the messaging will always be of debate, but this could always turn to a config option at a later date.
Extremely small fix, otherwise looks good to go