ok so maybe this isn't so much upstream. What is this insertTable plugin? Is it pure ck5 or is it some sort of core add-on?
ok we did find a workaround for table mangling, we disabled the insertTable plugin.
head of master and that build didn't help. Back to major, not much we can do, it's upstream.
Compiled 44.3.0 , did not fix the problem, trying the master branch of ckeditor5 now.
With that said, Wordpress is using TinyMCE . There's tens of millions of TinyMCE success stories and it worked great in Drupal 7 also. I believe it's time to bring back TinyMCE!
Unbelievable situation!
Tests were passing, now failing.
This involves dataloss so I would say critical bug.
Typo3 also reported this: https://forge.typo3.org/issues/105644
Ck5 Issues
Absolutely mind-numbing CK5 weirdness. After a month of being live with Drupal 11 and CKEDITOR 5, we descover this.
@phenaproxima, this is ready for merge. We merge this in, tests pass, then we can merge these fixes into the Drupal 11 upgrade merge request , it will be less changes for you to review at that point.
Thanks for all the hard work on this @Liam Morland and @danrod.
This is a critical issue for us as the layout_builder_st module is a release blocker for us. We need a tagged release in order to publish our tagged release for our distro (WxT).
a trick to break cache, on your url add ?t=random_number
Did you restart your varnish? Try testing with an incognito browser also.
Do a forced reload, you may have to reload your apcu service (opcode cache).
ctrl shift R
The required fix (code) is described in comment #12. There is a deprecated form validator to replace.
Important note:
The pipeline says there's one outstanding phpunit deprecation.
@danrod, there are only 4 test failures and they look related/similar.
Possibly that the test case is invalid. Need to set up a vanilla D10.4 / D11.1 and set up manually the test case(s) and examine the result. Something likely obvious at that point along the way. Possibly a test issue however need to do it and see.
Steps to reproduce:
Install Drupal 8, filebrowser, configure it
Upgrade to Drupal 9 with filebrowser, use it, add some records
Upgrade to Drupal 10.1 with filebrowser cofiguration, use it, add some records
Upgrade to Drupal 10.4 with filebrowser
Upgrade to Drupal 11
Drupal 11 requires PHP 8.3, which has the deprecated dynamic properties, some record carried over from previous Drupals results in needing this patch.
Found another issue after upgrading to D11
🐛
Deprecated function: Creation of dynamic property externalhost line 60 of src/Filebrowser.php
Active
Fix is in the merge request
joseph.olstad → created an issue.
While it shouldn't happen, it did for us and it is 100% content or revision related. We have about 6 environments of the same build. My copy is a production dump from before the client deleted users. In my copy, I do not see the exception however in the more recent production copy where the users were deleted there is an exception and the patch is needed in this case.
So 100% the configuration is the same in our test cases however the content is not the same.
@dabbor , sometimes you'll get better results using the diff instead of the patch, especially if you're doing a --dry-run test of it.
https://git.drupalcode.org/project/toc_api/-/merge_requests/16.diff
I have used the contact form in an attempt to reach the maintainer. Here is an extract of my message:
Hello Manuel, your great module needs Drupal 11 compatibility.
The code is ready, it needs you or a designated maintainer to take care of reviewing/merging/tagging and releasing.
I have been running Drupal 11 for a few months now, it's available for approximately 9 months. The time is now to release a compatible module.
https://www.drupal.org/project/fixed_block_content/issues/3430612 📌 Automated Drupal 11 compatibility fixes for fixed_block_content Needs review
Thank you,
Joseph Olstad
(phone number)
(email address)
Good idea
Suggested workarounds from comment #8 and related suggestions did not yield any clues. Patch 32 works for us. Our client deleted some users in prod that were involved in site building and some specific use cases involving content. Result is a WSOD for related environments when doing a node edit. The page in question has nothing special, just a node form with some normal fields. The reference to the user that is null is somewhere in a revision or as author/owner. This is about all the meta I can provide at this time.
Hitting this with D11 , client deleted a user
This actually fixes our problem in D11
D11 also needs this fix.
Without this fix we get a nasty error.
BEFORE:
The website encountered an unexpected error. Try again later.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "file_validate_extensions" plugin does not exist. Valid plugin IDs for Drupal\Core\Validation\ConstraintManager are: Callback, Blank, NotBlank, Email, Choice, Image, BlockContentEntityChanged, SourceEditingPreventSelfXssConstraint, CKEditor5Element, CKEditor5FundamentalCompatibility, CKEditor5EnabledConfigurablePlugins, CKEditor5ToolbarItemDependencyConstraint, UniqueLabelInList, CKEditor5ToolbarItemConditionsMet, CKEditor5ToolbarItem, StyleSensibleElement, CKEditor5MediaAndFilterSettingsInSync, SourceEditingRedundantTags, CommentName, ModerationState, CropTypeAspectRatioValidation, CropTypeMachineNameValidation, DateTimeFormat, EntityBrowserImageDimensions, QueueSize, FileSizeLimit, FileIsImage, FileExtensionSecure, FileExtension, FileNameLength, FileEncoding, FileImageDimensions, FileUriUnique, FileValidation, FileHashDedupe, LinkExternalProtocols, LinkAccess, LinkNotExistingInternal, LinkType, oembed_resource, MediaMappingsConstraint, ItemsCount, MenuSettings, PathAlias, RedirectSourceLinkType, SharedEmailUnique, TaxonomyHierarchy, Telephone, UserMailRequired, UserName, ProtectedUserField, UserNameUnique, UserCancelMethod, UserMailUnique, VideoEmbedValidation, InstagramEmbedCode, TweetEmbedCode, MenuTreeHierarchy, ContentTranslationSynchronizedFields, Count, UriHost, UniqueField, EntityBundleExists, ValidKeys, Range, CountryCode, Uuid, NotNull, AllowedValues, ComplexData, Length, Regex, Null, PrimitiveType, FullyValidatable, ConfigExists, LangcodeRequiredIfTranslatableValues, RequiredConfigDependencies, ExtensionName, ExtensionExists, PluginExists, UniquePathAlias, ValidPath, EntityUntranslatableFields, ReferenceAccess, EntityType, EntityChanged, EntityHasField, ValidReference, Bundle, ImmutableProperties in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).AFTER:
No error!
We need this! Reviewing
I see a beautiful new js file in the merge request. Is this js file even loaded by the cshs module? If so, how does it get loaded? How to test this.
Finally found a solution to this, in a hook_node_presave for example a client did this to fix it:
$entity_log_message = $entity->get('revision_log')->getString();
// Use a database query to get the current revision ID of a node.
$connection = Database::getConnection();
$query = $connection->select('node_field_data', 'nfd')
->fields('nfd', ['vid'])
->condition('nfd.nid', $entity_id)
->condition('nfd.langcode', $langcode);
$current_revision_id = $query->execute()->fetchField();
if (isset($current_revision_id) && is_numeric($current_revision_id)) {
$current_revision = \Drupal::entityTypeManager()->getStorage('node')->loadRevision($current_revision_id);
$current_revision_log_message = $current_revision->get('revision_log')->getString();
if ($current_revision->isPublished() && $moderation_state == 'draft') {
if ($entity_log_message == NULL && $current_revision_log_message != NULL) {
$entity->set('revision_log', ' ');
}
}
}
This likely will lead to a better fix.
joseph.olstad → created an issue. See original summary → .
Great, @danrod fixed all the phpstan errors and now the automated tests are passing for toc_api!
Thanks @web247!
@danrod, great work, fixing the phpstan issues appears to have also fixed the automated tests. 33 tests pass.
Yes thanks, I am the maintainer. We're using embed_block in D11 on ck5 without a fancy GUI interface that we had in ck4. There's work to do in the project and some of that could possibly involve a backport some of ck5_block_embed.
@brittany-willis, I've spent a lot of time fixing various issues with this module. For this reason before you evaluate anything with this module I highly recommend having a look at applying my merge request that fixes various bugs (likely more than advertised) as well as adds new functionality.
✨ Book TOC (Table of Contents) Active
3443839 ✨ Book TOC (Table of Contents) Active fixes some very serious bugs relating to the book_pdf module caching issues, especially when pertaining to having multiple language support and when you use revisioning you'll want a new revision id to indicate that a PDF has to be re-generated otherwise you'll see stale cached incorrect versions of your PDF and also if you support more than one language this patch ensures the correct language of the PDF is consistently made available.
Have a look at the book_pdfs → module, it is a fork of book_pdf. I did quite a bit of work on that, it offers header and footer.
https://www.drupal.org/project/book_pdfs →
with that said, the book_pdfs module would be a lot more useful if it was using the mpdf library instead of the dompdf library.
The dompdf library has some pretty bad limitations relating to tables that is why I made this issue to offer mpdf support:
✨
Add mpdf library support option and set it as the pdf library option
Active
I haven't tested 3482273 likely needs work.
Otherwise for the book_pdf module, I believe I did start some work on footer in the book_pdf module also
✨ Book TOC (Table of Contents) Active
Please test out the merge request for book_pdf. Otherwise have a look at these possibilities with the book_pdfs module.
Thanks
FYI, for those following this thread: There's a similar module for ck5
https://www.drupal.org/project/ck5_block_embed →
With that said, at some point I'll possibly backport some of this to improve the embed_block module unless I decide to refactor some other module integrations into ck5_block_embed instead.
@web247 yes that would help immensely!
Thank you!
Linking the plan for WxT 6.1.0
joseph.olstad → created an issue.
I believe this is ready for a subsystem maintainer review.
I created a new merge request because the branch name of the merge request was 11.x which is a confusing sort of branch name as it matches the branch name in origin. Perhaps was an accidental choice. In any case, I suggest moving forward with an appropriately named branch.
@kksandr, thanks for fixing the merge request!
When rendered, [#seven-digit-d.o-number] it looks like this:
🐛
Missing route cachability metadata in Drupal 10.4
Active
Thanks @clivesj , great stuff
BTW, I looked at the release notes, this is good, however I have a trick to make it easy that I do for my releases.
Have a look at one of
my projects release notes →
:
Have a look at this example code as a suggested example:
<h2>New in 3.1.4</h2>
<ul>
<li>
🐛
D11 compatibility hotfix for WSOD on settings page
Needs review
</li>
</ul>
<h2>New in 3.1.3</h2>
<ul>
<li>
🐛
Missing route cachability metadata in Drupal 10.4
Active
</li>
</ul>
joseph.olstad → created an issue.
@quietone ,
I faced a windstorm so far on this issue not only here but also in Slack. I've learned a lot though and had I to start this discussion tomorrow I would have a lot more knowledge and approach things in a much simpler iterative type of approach.
I'm a fan of pragmatism, a vastly simplified and reduced scale proposal such as the one we're currently at seems like a positive step forward that has the possibility of gaining traction.
@cmlara posted a fairly lengthy response in Slack about this. He said:
"The last change in policy seems like a good start, though time will tell if it succeeds....."
He goes on to say:
"I would like to see better planning, yes, "we will decide as we get closer" is a dislike". He goes on to say "set the dates and live by them, if something isn't ready pul it out to allow the deadline to be hit, do not be depending upon a secondary release window......
He also mentioned about engineers promises.
You hit a point on the head, for engineers promises matter, saying that and then jumping to "oh we could even cut support early" is the exact opposite of what Engineers want to see. We want to do an update and roadmap when they involve the next update so that we can deal with the dozens of other projects. " .....
Adjusted the scope to six months, but instead of for even numbered majors, now for all majors.
Simplifying the policy to a simpler one sentence idea.
Six months extra security coverage for majors.
Perhaps pre-mature to close this.
There's a whip effect to all this, where a decision or series of decisions made at the core level are a small ripple at the wrist, but by the time the ripple reaches the end of the whip its accelerated. The extra security coverage might seem like the end of the whip for your group however the lack of security coverage is the end of the whip for us.
jQuery 4.0.0-beta2 alone took me at least 500 deliberate steps to deal with where I now have taken ownership of additional libraries, projects and extra responsibilities related to this.
There's a lot of reasons why I now am asking your group to stretch. Its not just jQuery 4.0.0-beta2, it's an accumulation of all the flicks of the wrist coming from majors. All of the flicks of the wrist from the entire upstream.
There's also the sense of timing. We have a lot of clients to serve and the timelines do not cleanly line up. There's a ridiculous sense of urgency for every major in order to stretch our timelines and give the options for our clients.
Drupal is upside down compared to other projects. Microsoft for example eats it's own dog food, they run the next version of their own software before anyone else uses it. Acquia and the DA is the very last organization to switch majors. You've even advised me to delay upgrading until June at the earliest.
The timelines are so short that we had to complete our first upgrade by February.
Just keep doing what you're doing, we'll see where this all goes, we're basically rowing in the same boat but with radically different constraints and standards to follow.
Hi @ggh, thanks, had a quick look, it's looking pretty good, but there's some function name changes that make me a bit nervous.
Has any manual testing been done on this merge request?
@catch, thanks for pointing that out.
So ya, there's potential to offer say, an extra 6 to 11 months of security advisories without even negotiating an ES from Symfony.
I really hate to have to tell you this but @mcdruid and @poker10 did a fantastic job on security advisory releases and bugfix releases for Drupal 7. These two powerhouses could probably maintain an ES stream for 12 months in their sleep.
What are @mcdruid and @poker10 doing now that Drupal 7 is EOL? I would imagine they might be interested in such an initiative.
Perhaps you need to share the load and allow Drupal to grow while you have some margueritas in cabo and celebrate some recent milestone while core security advisory updates happen in your absense.
If we need more muscle to stretch things out 6 to 11 months, let's find some heavy lifters that can handle taking on security advisory coverage?
I updated the issue summary with those details, straight at the top of the issue summary.
This proposal is a one sentence proposal
Twelve months extra security coverage for even numbered majors.
Targetted ES for:
D12 / S8
D14 / S10
D16 / S12
D18 / S14
D20 / S16
D22 / S18
D24 / S20
D26 / S22
D28 / S24
D30 / S26
Even numbers would be ES, all odd numbered releases would be NON-ES
I'll repeat again, I am waiting to hear back from Sensiolabs on the cost of extending Symfony ES. Once we have a number, it’ll be easier to determine if this is viable. If official ES is not an option, then perhaps look at third-party ES models. (maybe there are some available now? Herodevs/Tag1/Others).
@nicxvan,
I've already read your thread on Slack and you're repeating the same accusations over and over again, there's nothing more to add, I already responded on there.
Is this worth it?
I'm hoping that SensioLabs is able to reply with a cost estimate that will provide guidance. How much will that cost the community? Not much if it's spread out, some may get it for free, others may spend a lot or contribute more. It's just like anything else, there's some that give, some that take.
There may be other capable vendors to be discovered other than SensioLabs, we'll see.
@ghost
Twelve months extra security coverage for even numbered majors.
Drupal 11 is an odd number, no extended security coverage for odd numbered majors under this proposal.
Some interesting discussions to gauge interest have led to a one-sentence proposal:
I've also reached out to SensioLabs to get an idea of the cost of providing 12 months of extended support for even-numbered Symfony majors.
It’s possible that other reputable vendors—beyond SensioLabs—may be willing and able to offer this extended support as well.
The sense of urgency comes from just having completed our first Drupal 11 production upgrade. Reflecting on the past 7 months of work, I can’t help but wonder if we could make this happen for Drupal 12 as the first even-numbered ES release.
Use ES terminology instead of LTS.
Postponed for a maximum 2 weeks, waiting for a response from Sensiolabs. Meanwhile, if someone has a better suggestion for other vendors, by all means please suggest another vendor that may be willing to and reputable enough to provide the extra 12 months of security updates for Symfony.