I'm facing a similar issue that looks related. If I edit a page published, any field like body, and save it as a Draft the menu configured lost the parent. When we publish that Draft the menu link will be in the wrong place at the main menu since it has no parent.
Any solution/suggestion for this issue? The client likes configure the menu links in the nodes and all the time they save a Draft the menu links lost the parent.
This patch updates the URL field changing from string to sting_long, allowing to save bigger URLs. The new field type will be added by default in a fresh install, for sites already installed, the hook_update will fix the current URL column on the reference's table.
From this
To this
The field on the edit page will look like this now:
This path is for 3.0.0-beta4 verion.
adrianopulz → created an issue.
Thanks for your fork @shreya_th!
The problem is for URLs created from the Request, URLs from the route will not be a problem. You added try/catch to the URL created from the route when the display['display_options']['path'] is set. We need the fallback only in the createFromRequest() call.
I've added a patch with the change example. I don't think we need to change the block of code using the UrlFromRoute.
adrianopulz → created an issue.
New patch for Drupal 10 fork. See:
https://www.drupal.org/project/ckeditor_entity_link/issues/3296754
📌
Automated Drupal 10 compatibility fixes
Needs review
This patch fixes the issue when using the Drupal 10 fork.
Hi there! I'm facing issues with this fork since the composer.json file in the root module folder has these requirements:
<?PHP
"require": {
"php": ">=7.1",
"drupal/message": "^1.0",
"drupal/message_notify": "^1.0",
"drupal/core": "^8.8.0 || ^9.0"
},
?>
Could we update these items as well? My suggestion is to use PHP 8.1 and core ^9.4 || ^10.
Another option is to use >=7.4 || >=8.1 and core ^9 || ^10.
After updating tho this Fork in order to have D10 compatibility, I'm facing this error when trying to clear the cache.
Service 'twig_extensions.twig.array' for consumer 'twig' does not implement Twig\Extension\ExtensionInterface.
Backing tho the latest release version, the error stops. Any help with that?
adrianopulz → made their first commit to this issue’s fork.
adrianopulz → made their first commit to this issue’s fork.
This patch is to be used with this issue fork: https://www.drupal.org/project/ckeditor_entity_link/issues/3365412#comme... ✨ Link to the Media page removed Needs review
The patch with the changes. That will add a checkbox if "Media" is selected on the Form.
Flagging it the link will point to the Media canonical page.
adrianopulz → created an issue.
It worked fine on Drupal 10 and fixed the problem. Great work @icurk!
I've created this patch changing the way the module adds the library to the form. I also changed the hook to a more specific one that will include the script only for Node forms instead of any form. Adding the library to the main's form ['#attached'] value make the trick. It worked for me and the "(browse)" link start to be displayed in the Menu field.
adrianopulz → created an issue.
I'm facing the same issue after updating to Drupal 10.0.9. No special step to reproduce, I've updated all modules and core to the latest D9 version. After that, I upgraded to Drupal 10. I executed the drush cache rebuild and updb.
Now I have this same message "ajax.$form.ajaxSubmit is not a function".
Hi @yogeshsevak! The fixes are looking good. I will test after updating the project to D10. I was sending the same patch fixes because yesterday I didn't see any patch with full fixes. Thanks!
I've created this patch that changes the deprecated file_create_url() function in order to use the file_url_generator service. The media file path is returning directly the string from the method generateString().
This method will return the proper URL depending on the current File System, it may be a local URL (matching domain), a root-relative string containing a URL that may be used to access the file. An absolute URL may be returned when using a CDN or a remote stream wrapper.
See more info here: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21File%21Fi...
adrianopulz → created an issue.
Thanks jonathan1055! That has solved the problem.
I didn't see that on the home page, I went direct to the issues list... A message when the Moderation module is enabled will be very helpful.
I'm facing the same issue with the unpublish action. Checking the logs all looks good, Drupal CRON runs and the message is that the node was unpublished, but the node is still published.
I've just tried to install this module in a https://simplytest.me/ for testing and it is not working. Is it supposed to not install in a fresh Drupal? I had the same issue installing this module locally with Composer + Drush, is it a GovCMS issue?
I have the GovCMS PasS configured to a 2-year-old project that we update to the latest GovCMS version periodically. I've updated it to the latest version yesterday and it adds the hook_update installing those log track modules in the govcms_security module.
I've tried manually using drush en only to test if it was an issue on the hook_update or to install the module. Since locally downloading it by composer and installing using drush return the same error I had deploying the updates on Gitlab I'm not sure about the origin of the issue.
Yes, I installed using composer + drush to enable the modules. It is weird.
I've installed a group of modules. The modules I tried to install are:
- event_log_track
- event_log_track_auth
- event_log_track_config
- event_log_track_menu
- event_log_track_node
- event_log_track_syslog
- event_log_track_tfa
- event_log_track_ui
- event_log_track_user
It is part of the GovCMS and there they install those modules in a Hook Update. I had an issue deploying this because of the errors I mentioned. I also tried locally to install them manually, one by one, but I had issues with some of them.
https://github.com/govCMS/GovCMS/blob/2.x-develop/modules/custom/core/go...
I thought it was a GovCMS issue, but after trying to install it manually looks like something on the Events Log Track module. The modules after clearing the cache and trying to install the module again it says the module is already installed, so looks like the error is not blocking the installation, in the other hand in an automatic deployment the error breaks the deployment process.
adrianopulz → created an issue.
Hi @ysamoylenko!
Yeah, that looks great. I'm using Azure Redis as well.
The $info needs to be verified before using it to avoid PHP errors.
Thanks for the patch. =)
adrianopulz → created an issue.