I have the same problem where CKEditor 5 broke when I upgraded Drupal to 10.3.
I do not have ckeditor_templates_ui installed though. I know this issue is for ckeditor_templates_ui but I believe this is a wider issue affecting more CKEditor modules.
In case this is still helpful for future resolution, my error is:
ckeditor5.js?sfp0r8:468 CKEditorError: plugincollection-plugin-not-loaded {"plugin":"TrackChangesEditing"}
Read more: https://ckeditor.com/docs/ckeditor5/latest/support/error-codes.html#error-plugincollection-plugin-not-loaded
at l.get (ckeditor5-dll.js?v=41.3.1:5:123474)
at r.afterInit (drupalMediaTrackChangesIntegration.js?v=20240220:5:958)
For anyone using a custom theme who is stuck with this, I was able to fix this using the below CSS:
article {
width: fit-content;
}
I went through a lot of steps finding the issue. It turned out that the media was being added correctly, and while the image element itself was missing align: centre, but a few levels up the parent elements did get this attribute. I played in the browser a bit and found that by setting article to fit-content, it suddenly worked.
After trying the solutions, here is my results:
1) Using drush field:delete
I attempted to run drush field:delete field-name=field_audience
During the prompts, I answered 6 (content) and 0 (Quick Action - the name of my content-type)
I had high hopes for this method, but sadly it resulted in a very similar error as when I did it through the interface:
In ExceptionHandler.php line 56:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_audience_target_id' in 'where clause': SELECT 1 AS "expression"
FROM
"node_revision__field_audience" "t"
WHERE "field_audience_target_id" IS NOT NULL
LIMIT 1 OFFSET 0; Array
(
)
In StatementWrapperIterator.php line 111:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_audience_target_id' in 'where clause' 2) Next I tried using drush cex and drush cim to delete it, but sadly this also had a SQL error:
In ConfigImportCommands.php line 290:
The import failed due to the following reasons:
Unexpected error during import with operation delete for field.field.node.quick_action.field_audience: SQLSTATE[42S22]:
Column not found: 1054 Unknown column 'field_audience_target_id' in 'where clause': SELECT 1 AS &q
uot;expression"
FROM
"node_revision__field_audience" "t"
WHERE "field_audience_target_id" IS NOT NULL
LIMIT 1 OFFSET 0; Array
(
)
Unexpected error during import with operation delete for field.storage.node.field_audience: SQLSTATE[42S22]: Column not
found: 1054 Unknown column 'field_audience_target_id' in 'where clause': SELECT 1 AS "express
ion"
FROM
"node_revision__field_audience" "t"
WHERE "field_audience_target_id" IS NOT NULL
LIMIT 1 OFFSET 0; Array
(
)
In ConfigImportCommands.php line 276:
Errors occurred during import
3) Manually alter database
Honestly I had no idea what I was doing, so I am surprised this solution finally worked. To accomplish this, I opened MySQL and ran DESCRIBE node_revision__field_audience; and DESCRIBE node_revision__field_audience_2; to get a comparison of both tables schemas. I found that the field_audience_2_target_id was int unsigned, not null, key MUL, and default null.
After some research I found that you first have to alter the table to add the column, and then alter it a second time to add an index to this new column to make it key MUL.
-- Add the column
ALTER TABLE node_revision__field_audience ADD COLUMN field_audience_target_id INT UNSIGNED NOT NULL AFTER field_audience_value;
-- Add the multiple index
ALTER TABLE node_revision__field_audience ADD INDEX idx_field_audience_target_id (field_audience_target_id);I did not delete the field_audience_value column as I went back to the Drupal interface to see if I can now delete the field.
I was pleasantly surprised to see that this worked with no further errors.
Conclusion
I am mildly frustrated at the inconsistency when creating fields, especially since I could potentially lose hours of work if I am spending a day creating views and fields only for one of the fields to break a database table. I am not sure how it is possible for the field to be created in such a way that it cannot be deleted except after manual intervention, so I'm not sure if this is because of a custom module or because of a bug in core. I am not yet experienced enough to create something like this myself, but I hope that some day Drupal would have a function to log and rollback database changes that break tables, although I appreciate the difficulty in creating such a feature. Maybe some day I can tackle this if I become smart enough!
This said, I do appreciate the experience I gained from working through this issue today and resolving it, and I especially appreciate your help VM for setting me on the right track!
These are tremendously helpful resources. Thanks for taking the time to answer! Once I find my answer I will update this post with the solution I went with in case it helps someone in the future.
Hi @andileco, I am okay with PHP, but I found a solution that worked in views alone, although I had to compromise and enable stacking on my column chart. I'll include the solution below in case other users find it useful.
Solution
As with other Charts, it's best to start off with a table as this can later be changed to a Chart once you're happy with how the table looks.
1. Enable Aggregation as this will be needed for next steps
2. Add the "Authored on" field and set the aggregation to group results. I named this one "Month" as it will show the month name once all the steps are followed.
3. Add the "Authored on" field once again, but this time set the aggregation to count distinct. I named this one "Submitted" as it results in how many change requests exist that month.
4. Add additional data columns. In my case, I added the "Success" field which is a list with "Fully successful", "Partially successful" and "Unsuccessful" where only one option can be selected. Set the aggregation to group results.
5. Add a new Sort Criteria. I added "Authored on" here and set the granularity to "Month" which is what ends up sorting the previously defined fields into months and allows the chart to chart the data monthly.
6. Change the format to chart. In my case, I set this to be a column chart as it shows monthly data in an easy to read way.
7. Change the chart settings. I set the label to be "Month". I also enabled stacking which is what resulted in the chart showing actually useful data. Finally I added submitted and success as data fields.
Stacking
This is for anyone not familiar with stacking. Essentially, as the name implies, this stacks data points with multiple possibilities into a single column. In my case, each change request can be set to either fully successful, partially successful, or unsuccessful, but the total number of change requests stays the same. This results in a column on the chart that stackks different colors representing how many fall into the different success categories. All together, they add up to the total number of change requests, so one column is able to show both the total number submitted per month, and how many fall into each different category. It is not as easy to read as separate columns representing each success, however it takes up far less space and actually looks much nicer in my opinion. The main benefit of this is that instead of having 3 columns for each month, which would result in 36 columns, it can show the same data in only 12 columns.
Hi there, I just wanted to reply to this issue as the original user never replied to confirm whether or not this works.
I tried the hook alter with the raw options and this unfortunately did not work for me. What did work for me is:
function my_module_chart_alter(array &$element, $chart_id) {
$element['#title_font_size'] = 20;
$element['#title_font_weight'] = 'bold'; // Adjust font weight as desired
$element['#title_color'] = '#004B78';
}
I am not sure if this is the right way to do it, but it did work for me. I am also not sure what would need to change for the #raw_options method in order for it to work.
ciesinsg → created an issue.
Hi Roderik, thanks for all your help with this. We were able to discover the issue so I wanted to include this here in case it helps anyone.
The issue was that the transfer instance was setup with the wrong directory name. Even though the directory I was working in was cabstg, the actual server was set to cab so the URLs I made simply didn't exist on the server. After the transfer instance and server were made to match, and I corrected the absolute paths, it is working as intended.
@roderik Thanks for the suggestion. I modified the script to include
echo "open_basedir: " . ini_get('open_basedir') . "\n";
But when I run this from PHP cli this just outputs "open_basedir: " and nothing afterwards as if there is no basedir set. I am not sure exactly what this means as this seems to be a different outcome than you mentioned. Does this mean that there's no basedir set, or is this variable hidden to me?
ciesinsg → created an issue.
Hi Roderik, thanks once again for assisting with my query. I have found a working configuration that resolves the protocol issue very simply. It seems that it is a match your suggestion as well:
$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = array($_SERVER['REMOTE_ADDR']);
For Trusted headers, I checked with my server team to see which header we are using, so I imagine this part could differ depending on server specifics:
$settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_PROTO | \Symfony\Component\HttpFoundation\Request::HEADER_FORWARDED;
The site is now generating the right ACS Url using https instead of http.
ciesinsg → created an issue.
I made some progress with this issue. I believe that the External Authentication dependency is what is responsible for creating the authmap table.
After checking the update from Roderik, it looks like this is correct! Thanks for the support!
In my case, I was able to get rid of the issues locally by uninstalling all of the SAML modules, as well as the External Authentication. After this, I removed "drupal/samlauth": "^3.9", from my composer.json file and ran composer update. Then, I started the installation over, but I was hesitant to simply checkmark all four modules like I did the first time I installed. Instead, I installed in the below order:
External Authentication -> SAML Authentication -> SAML Auth User Fields Mapping & SAML Auth User Role Assignment
I'm not sure if this order is necessary, but it seems to have resolved my issue and eliminated the errors I encountered during login and configuration.
When pushing to staging, I had to repeat this process. In the staging environment, I had to manually uninstall all four modules. I didn't have to update the composer files, so this step may not be necessary. Then, I installed the modules in the same order as above. Once again, this resolved the errors I was encountering in local and staging.
ciesinsg → created an issue.
Is there any work around for this issue while we wait for a patch/update?
Regarding #27 🐛 Date range - offset one day Needs review , unfortunately I don't know how to make a patch for this either, but hopefully someone sees your comment and gives some input on how this can be done.
Did you ever figure this out? Getting the same error and not much help to resolve it.
ciesinsg → created an issue.
Thank you for the reply. It took me a little bit of time to understand it as I am still very green in Drupal, but it is working now.
For anybody who needs this in the future, the solution is to create a new module. I used these instructions to create a basic module. In the mymodule.module file, I needed to put the following code:
<?php
/**
* @file
* This file loads custom configurations into core ckeditor.
*/
use Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition;
/**
* Implements hook_ckeditor5_plugin_info_alter().
*/
function ckeditor_config_ckeditor5_plugin_info_alter(array &$plugin_definitions) {
if (isset($plugin_definitions['ckeditor5_table'])) {
$table_plugin_definition = $plugin_definitions['ckeditor5_table']->toArray();
$table_plugin_definition['ckeditor5']['config']['table']['defaultHeadings'] = [
'rows' => 1,
'columns' => 0,
];
$plugin_definitions['ckeditor5_table'] = new CKEditor5PluginDefinition($table_plugin_definition);
}
}
Then, all that was left was to install the module in the extend menu.
Also worth noting, this does NOT take effect for existing tables created with CKEditor. It is necessary to edit that content, and create a new table. The new tables will have the headings as defined in this file. This caused me a bit of confusion as I was under the impression that it was not working at first.
ciesinsg → created an issue.
@matthieuscarset the content structure is pretty big unfortunately as the company needs to collect a lot of info in this form. It is essentially a node: event, two date fields, four separate taxonomy fields, three string lists, three integer lists, and maybe a dozen Text (plain long) fields. The only custom type I am using is a fieldset that groups the types visually for the form, and the rest are core types.
@sdsheridan thanks for reopening that issue. I don't see any solution though, it just looks like you found the source of the bug and the issue has been reopened to resolve it. I am not in a rush so I will keep an eye out on it to see if it is updated soon.
ciesinsg → created an issue.
These are amazing and exactly what I was looking for! Thanks for sharing this with me.
Thanks for the suggestion! I will look into those modules and the patches you suggested.
I was curious if there is any other way to make the images responsive without using modules? I tried to target them with CSS, but for some reason my CSS wasn't being applied to the images and it was using their attributes instead. I haven't been able to find any docs or blogs that cover alternate styling methods, but I am hesitant to introduce too many modules and I would love to learn more about how the images are served and how they can be made responsive using code/styling instead of modules.
I was able to resolve the issue. I posted the solution at this stack overflow question.
I will say though that the current process to disable caching and enter development is still too complicated. The info available in the docs doesn't seem to work for many people, and everybody has different answers for what it could be. Additionally, it seems that some fixes work on some environments but not on others. I am hoping that a future Drupal release can address this issue and make it easier for people to jump into and out of dev mode.
I spent the whole day trying to disable caching for development.
1. Set Caching to <no cache> in Performance
2. Found this q/a which suggested changing .htaccess. Edited the .htaccess file in /web/ (my root) to include:
<IfModule mod_rewrite.c>
RewriteEngine on
<FilesMatch "\.(html|htm|js|css)$">
FileETag None
<IfModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 12 Jan 1980 05:00:00 GMT"
</IfModule>
</FilesMatch>
</IfModule>3. I ensured httpd.conf is loading mod_rewrite
4. I also added EnableSendfile off to httpd.conf
5. I removed version: VERSION from my info.yml and libraries.yml files
6. I uncommented # $settings['deployment_identifier'] = \Drupal::VERSION; in settings.php
7. Restarted the Apache service after every step
Unfortunately, none of these solutions did the trick. I am pretty frustrated at this point as it is very time consuming to manually flush the cache and no matter what I try, I am not able to disable it.
Thanks for the detailed explanation and linking your blog. I am working my way through it as it is packed with really helpful information, but it has already clarified a lot.
Hi Jaypan, thanks for the advice. That sounds like it will work, but I am still fairly new to Drupal and I'm not sure how to "Delete the site" in a way that I can reinstall it afterwards. Is this a matter of deleting a folder, or something I need to do from the administrative panel?
I discovered the fault causing the duplicate labels. It looks like the Sort Criteria had an "Authored On" configuration that was causing issues with the aggregation including duplicating labels. Removing this configuration from the Sort Criteria resolved the issue.
Wow, it looks like authored date was in fact the issue. Removing this automatically resolved my aggregation issues and I was able to generate charts successfully.
Thanks for the help!
I edited my question to be more concise and to include more relevant info.
Bump.
ciesinsg → created an issue.
Hi @andileco, thanks for the tips! I did try using the attachments yesterday but unfortunately I was unsuccessful. What happens is that the attachment chart changes the initial chart I create. Thankfully I discovered the solution, so I will outline it below in case it helps someone in the future:
Recreate Issue
In this example, I have one content type "change request" and I was creating two charts from the fields: category and reason.
1) + Add View - name the view, show content of type change request, checked the "create a page" option, and display a chart of fields.
2) Set up my first chart on this page. I added the category field for the labels, and a second counted category field to count the number of posts per category.
3) Modified the settings on the chart (Format -> Chart settings) to use the label and data field and successfully outputted a "category chart".
4) Clicked "+ Add" and selected attachment. In the Attachment settings, I attached it to Page (initial chart), changed position to after, and enabled "Inherit exposed filters". The rest of the settings on the attachment seemed to be cloned from the original page, including the fields I added and the chart settings.
5) Added the reason field for the labels, and a second counted reason field to count the number of posts per reason. During this process, I selected the option "For This attachment (override)" so that the fields successfully added only for the attachment.
6) Once again I went into the chart settings (Format -> Chart settings) and changed the chart information. I changed the title, labels, and data, however there was nowhere that I could select that previous option "For This attachment (override)". The result was that both charts changed and showed the labels and data for "reason".
Solution
So it seems that the "Format -> Chart | settings" option doesn't have the "For This attachment (override)" option, at least not in Drupal 10. Instead, you have to click Format: Chart | Settings (click chart) on the attachment, and there you can select the attachment as override. Once you do this, the settings are changed only for the attachment and the previous chart remains unchanged.
I wanted to include this explanation because this option is easy to miss and I completely missed it yesterday.
ciesinsg → created an issue.
I just wanted to add an update as I have been working more on this content type today and the button is now mysteriously appearing. I am wondering if this is something to do with caching and it may have been automatically resolved by CRON. I am pretty new to Drupal and I do not know enough about this yet to perform any kind of investigation as to why it didn't work yesterday and why it suddenly works today.
Great suggestion, I will try this. Thanks for the link and the quick reply.
ciesinsg → created an issue.
I am experiencing the same issue.
I downloaded and enabled the Field Group module and attempted to use it to modify the form of a custom data type Change Request. At first, I thought it wasn't working at all since the Add Field Group button was not visible in the Manage form display tab of my Change Request data type.
I stumbled across this issue and realized I should check the Page and Article data types that came with my Drupal installation. Surprise surprise, the Add field group button is perfectly visible on there. I'll admit, I wasn't able to find any documentation for this module so I do not know if I am doing something wrong or if this button should be visible on all custom data types within the Manage form display tab.
Anyway, I included the screenshots of page/form-display where it is working, and change_request/form-display where it is missing.
I also wanted to add that the workaround posted in this post works for me as well. If I go to the change_request/form-display/add-group URL I am able to add the group, I just don't see the button.
Apologies for the confusion. I am very new to not only Drupal but also database administration and cron, so I incorrectly thought cron was a Drupal specific term.
Thanks for your time!