It must be a caching issue. I'm using Chrome primarily but I also use FF and Edge and it appears normal. I'm on Mac OS. Perhaps there is an issue with Windows/Chrome but I haven't been made aware of it by any of my clients who are on Windows and use Chrome.
@stevenpatz, I have the same versions of Drupal and IMCE as you and it is working correctly on mine. Did you disable image uploads in Configuration -> Content Authoring -> Text Formats and Editors ? Under image, enable image uploads should be unchecked.
Experiencing the same issue on a Drupal 10 site.
#20 has fixed the issue
No loop problem detected yet.
I can affirm that this is an issue that occurred between core versions Drupal 10.3 and Drupal 10.4.
Every one of my Drupal sites that were updated to Drupal 10.4 have lost the ability to access the IMCE file manager from the Core CKEditor image tool.
I don't see any errors in the Javascript console or the error database and the CKEditor has been set for Images not to use the upload feature in Core which should enable IMCE to work with it. Something must have been changed in core to disable IMCE integration.
Cheers,
Andrew
Hi Bryan,
The CiviCRM Entity module devs have indicated that it's unlikely I'll be able to resolve this issue without custom coding my own Views field plugins so I'm going to close this as works as designed and carry on.
It's a very cool module though so I'll be using in again when I can. I may poke around and see if I can add a custom views field that works in tandem with it where I can override the database connection to assign the one for CiviCRM. I think that would work but it would probably be easier to just write a purpose built plugin for this one specific job. I've got Views field plugin boiler plate code I can borrow from a recent project that did something similar with a remote data warehouse.
Thanks again for the help.
Cheers,
Andrew
Hi Bryan,
Yes, both databases are on the same server which is pretty standard for the Drupal/CiviCRM sites that I maintain. CiviCRM entities are made available to Drupal via a CiviCRM Entities module.
I've been developing in CiviCRM since Drupal 6 and prior to Drupal 9/10 we used to add a hard coded DB array to the settings.php file to tell Views about the CiviCRM database. It was the form of:
$databases['default']['default']['prefix']= [
'default' => '',
'civicrm_acl' => '`database_civicrm`.',
'civicrm_acl_cache' => '`database_civicrm`.',
'civicrm_acl_contact_cache' => '`database_civicrm`.',
'civicrm_acl_entity_role' => '`database_civicrm`.',
. . . More definitions . . .,
];
I've opened up a conversation of the mattermost channel that handles the CiviCRM Entities module to see if there is a database api method that recognizes the database that is responsible for the appropriate entities.
The actual error I get is as follows:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database_civicrm.civicrm_event' doesn't exist: SELECT node_field_data.nid AS "nid", NULL AS "civicrm_event_start_date", NULL AS "id", :view_combined_event_listing_block_1_combined_event_listing_block_1 AS "_view_id", NULL AS "_order_0" FROM "node_field_data" "node_field_data" WHERE ("node_field_data"."status" = :db_condition_placeholder_0) AND ("node_field_data"."type" IN (:db_condition_placeholder_1)) UNION SELECT node_field_data.nid AS "nid", NULL AS "civicrm_event_start_date", NULL AS "id", :view_drupal_event_listing_default_drupal_event_listing_default AS "_view_id", NULL AS "_order_0" FROM "node_field_data" "node_field_data" WHERE ("node_field_data"."status" = :db_condition_placeholder_2) AND ("node_field_data"."type" IN (:db_condition_placeholder_3)) UNION SELECT NULL AS "nid", civicrm_event.start_date AS "civicrm_event_start_date", civicrm_event.id AS "id", :view_events_listing_default_events_listing_default AS "_view_id", civicrm_event.start_date AS "_order_0" FROM "civicrm_event" "civicrm_event" WHERE (("civicrm_event"."is_active" = :db_condition_placeholder_4) AND ("civicrm_event"."is_public" = :db_condition_placeholder_5)) AND (((DATE_FORMAT((civicrm_event.start_date + INTERVAL -25200 SECOND), '%Y-%m-%d\T%H:%i:%s') >= DATE_FORMAT(('2024-12-10T07:00:00' + INTERVAL -25200 SECOND), '%Y-%m-%d\T%H:%i:%s'))) OR ((DATE_FORMAT((civicrm_event.end_date + INTERVAL -25200 SECOND), '%Y-%m-%d\T%H:%i:%s') >= DATE_FORMAT(('2024-12-10T07:00:00' + INTERVAL -25200 SECOND), '%Y-%m-%d\T%H:%i:%s')))) ORDER BY "_order_0" ASC LIMIT 11 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => drupal_event [:view_combined_event_listing_block_1_combined_event_listing_block_1] => combined_event_listing:block_1 [:db_condition_placeholder_2] => 1 [:db_condition_placeholder_3] => drupal_event [:view_drupal_event_listing_default_drupal_event_listing_default] => drupal_event_listing:default [:db_condition_placeholder_4] => 1 [:db_condition_placeholder_5] => 1 [:view_events_listing_default_events_listing_default] => events_listing:default )
If I can't find a solution that uses the database API, I'll likely just write a module and run the queries in code. Hopefully I can though because this would make a lot of Drupal/CiviCRM listings better; not just events but newsletters and other things that would benefit from being listed together.
Cheers,
Andrew
awasson → created an issue.
I have also been struggling with this issue on my Full HMTM editing profile. My Basic HTML is fine.
It happened after upgrading to CKEditor 5 in Drupal 10 from CKEditor 4 in Drupal 9.
For me, this involved upgrading the Anchor Link module from CKEditor 4 to a CKEditor 5 version.
I found that the library for Anchor link was not loading and throwing an error that basically crashed the JS interpreter and stopped all of the other JS from running. I would check to make sure that any additional plugins that your using on the text editing profile that is causing issues are not having conflicts.
Cheers,
Andrew
I just realized, I should change this to Needs Review.
Cheers,
Andrew
@thorsch, Unfortunately, I've had to move on and am migrating the long-hand way with drush migrate tools.
Acquia Migrate: Accelerate really looked great when it arrived last year but now, it seems to me that there are two issues:
1) Drupal 9 modules that Acquia Migrate: Accelerate tries to map to the Drupal 7 modules in the source site are no longer available via composer.
2) Something in Context changed to make Acquia Migrate: Accelerate delete 90% of my site.
Beyond that, none of the maintainers seem to be paying attention to the issue queue. I maintain a couple of much less complex Drupal modules, so I understand the overhead of the issue queue but I can't wait so I've moved on. DrupalCon is in December this year so maybe there will be some announcements. If you can wait, it might be worthwhile.
In the meantime, there is another module to look at: https://www.drupal.org/project/migrate_wizard →
Cheers,
Andrew
awasson → created an issue.
Sounds like a good plan.
I'll add that to my todo list.
Fixed. Will be on the next release.
Patch #3 works for me too.
The patch was rolled 5 years ago. Perhaps the module maintainers can release a stable version with this patch as now that most sites are on PHP 8.1 or better, this is no longer a warning and it now crashes the Ajax response and renders the form useless.
Cheers,
Andrew
I am experiencing this exact problem as well. In my case, I have the choice of 4 options with 4 corresponding field sets to show.
I have done this with much, much more complex choices in the past and have not had a problem however now I get the illegal choice error and my additions are not allowed. This appears to be happening when I add a few conditionals and then decide to add a new one to the mix. When I add the new one, it will trigger the illegal choice problem.
I have discovered a workaround. It is a bit tedious but it requires you to delete your existing conditionals and add them all at once before saving the conditionals. I've done this several times to make certain this is the case and if I do delete the existing conditional rules I can add all 4. If I need to add a 5th, I then need to delete the existing 4 and add them all at once again.
It is tedious but it works.
This is the case with the existing DEV released 28 Jul 2023 and the 7.x-4.26 Stable release, released 28 September 2023.
Cheers,
Andrew
FYI to anyone having trouble with this issue.
This hasn't been fixed in the 7.x-3.x branch. It has however been fixed in the 7.x-3.x DEV branch.
Cheers,
Andrew
Perfect! After following the blogpost by Wim, it was up and running, fast, thorough and foolproof!
Total game changer.
Cheers,
Andrew
@hockey2112, It sounds to me like the bootstrap theme is overriding the FieldFormatter class in Image Link Formatter or overriding the Field Formatter template in Image Link Attributes.
If the theme has a twig template for the image formatter and the theme uses some kind of variation on template_preprocess_image_formatter() then that would do it. The them may also just be overriding the Core ImageFormatter and the one inside Image Link Formatter.
Andrew
Thank you. Glad that it's no just me.
Thanks @inversed #21 🐛 Drupal 10 compatibility Fixed ,
Perhaps a maintainer can post that suggestion to the module page under preparing for Drupal 10 to save time and frustration for those running into this issue.
I too have run into it multiple times in the last weeks while preparing sites for upgrading D9 -> D10
I've been editing composer.json manually for:
"drupal/better_exposed_filters": "^6.0.3",
"drupal/jquery_ui_datepicker": "^2.0",
Then composer update.
I think your method is a cleaner way to do it.
Cheers,
Andrew
The patch works perfectly for me.
I don't think the automated test against PHP 8.2 & MySQL 8, D7 is a representation of this patch and more than likely exposes other areas of the module that need to be updated for PHP 8.2 & MySQL 8.
I see no reason why this can't be set to Reviewed and Tested by the community so it can be rolled out but perhaps someone else can weigh in on it to see any issues.
Cheers,
Andrew
Oops. I think the patch will have to be rerolled against the latest dev before running a test.
It is still working for me and is necessary.
I see no errors reported in my Recent log messages. I see it passes against PHP 7.2 so I've just queued it for a test against PHP 8.0.
Drupal 9.5.11
Direct Checkout by URL 8.x-1.1
Cheers,
Andrew
Hi Eirik,
It seems that the patch is effective. I didn't install it but I can attest to it being effective. I'll contact the Dev who patched it and get some more feedback.
Cheers,
Andrew
Can the maintainer weigh in on whether this issue is outdated or if it still needs review?
I am maintaining a site that has had this patch applied and I can't update the site via composer because this patch has been applied and composer sees that
drupal/direct_checkout_by_url has modified files:
M src/Controller/CheckoutByUrlController.php
M tests/src/Functional/RedirectTest.php
Thanks,
Andrew
Thanks @bill_redman,
I'll test it on a clean installation to make sure that there are no issues and then update the module page. I'm glad it works better than expected.
Cheers,
Andrew
Workaround in #8 worked for me too - thanks @jayemel
Hi guys,
I'm postponing this issue. Because CKEditor 4 is going to become unsupported at some point in the coming months, I need to evaluate the big picture on how it works with the CKEditor 5 that ships with the latest Drupal.
Thanks for the effort and especially thanks to @apaderno for explaining the context of the files that were copied from the CKEditor package and the use of NULL and null.
Cheers,
Andrew
Done and done. I'll tag a new release with this feature in the next few days.
Here's the patch. I've tested it and it has no issues. I'll leave it as needs review and commit it after I've tested it thoroughly.
Patch applied and committed to Dev. I'll tag a new release soon.
Patch attached
I've got some other things to deal with first, then I'll look at adding a config page where we can add custom attributes. It's not going to happen overnight but I've done something similar with another module so I've got some ideas.
Cheers,
Andrew
I think this will probably evolve into the ability to add custom attributes to image links per the issue here: https://www.drupal.org/project/image_link_attributes/issues/3322434 ✨ Add any custom attribute Active
The attached patch provides for Responsive Image formatting with attributes for target, class & rel.
Hopefully this will allow the patch to pass the tests. If not, I'll have to reach out to the maintainer to see if he can assist.
Cheers,
Andrew
I think the reason why this is failing tests is because my patch doesn't accommodate for Responsive Image Link wrappers... Yet.
I'll have to do some more work and submit another patch.
Here we go again...
Attaching another patch with a schema file that will hopefully pass testing and changing to Needs Review. I'm not sure about the other tests but the majority of the failures appear to be the result of not including a schema file.
@MukhtarM, Thanks for reviewing and testing the patch. Hopefully the maintainer will have a moment to review this and weigh in on it as well.
I'm updating the issue with a new patch that includes hook_update_N() to make drupal install the config file that contains the target attributes and those for the class and rel attributes. This way, anyone who is using the existing module won't have to uninstall and reinstall the module in order to get the attributes. All they'll need to do is update the module and run the database updates.
I've also changed the status to Needs Review and assigned the issue to myself.
Cheers,
Andrew
New Patch to remove the coding standards messages.
Uploaded another patch. I noticed that there was a line of troubleshooting code in the original.
Make sure that you run update.php after patching the module so that you get the updates to the module config, which contain the attributes and targets.
Cheers,
Andrew
Hey, to anyone who's following this issue. It looks to me as though this issue was related to how the Paragraph API handled fields and since it was originally created, the Paragraphs API has evolved and now works well with the Image Link Attributes module. That being the case, I'm going to close this as "Work as Designed". Feel free to open it again if there is new information regarding this issue.
Cheers,
Andrew
Just adding the related issue from my issue queue at Image Link Attributes.
Cheers,
Andrew
I really do think that Image Link Formatter should have the ability to add attributes natively so I've created a feature request issue on Image Link Formatter and posted a patch that will provide those features. You can find it here: https://www.drupal.org/project/image_link_formatter/issues/3378313 💬 Add link attributes and target natively. Needs review
It's going to need a tiny bit of fine tuning to add hook_update_N() to update the module config and make it aware of the changes but it's pretty much ready to go so I'm going to set this one as Closed Duplicate and refer to the Issue at Image Link Formatter.
Thanks to all who have been following this issue.
Cheers,
Andrew
Patch added.
@Nelo_Drup
Thanks for the clarification on a use case. I think I understand exactly what you want to do.
I think it would be better if the Image Link Formatter module had that capability built in so I'm going reach out to the maintainer of that module and extend his module to add the ability to add attributes natively. I've got a proof of concept running locally and I'll send a patch to see if he wants to add it to his module.
Cheers,
Andrew
@jefferyVincent
i know this issue has been languishing for some time but if you have a moment, can you have a look at this issue again?
In order to test this, I created a paragraph type with a title field and an image field. From within the Paragraph Display Settings, I have been able to access and add image links attributes in the same way that I can from an image field within a content type. Everything appears to be a-ok.
I'm not sure if this is a result of changes within the paragraphs API but I suspect it may be.
Cheers,
Andrew
@apaderno, I'm just reviewing issue queue items.
Can you let me know the use case that required compatibility with Image Link Formatter?
Thanks,
Andrew
@GuyPaddock, thanks for lodging this issue.
I think the reference to image_link_attributes.config was an artifact from an earlier approach I was taking and it was never removed. I'll have to consider whether it's necessary to have a config page for the module. At the moment, I'm leaning towards deleting the reference from the module but I have some other plans so I may indeed add a route and form. I'm going to postpone this for the moment and I'll open/resolve it when I decide what I want to do with it.
Cheers,
Andrew
@Mistrae, I haven't forgotten about your Feature Request.
I think this is a great idea.
I'm not sure how to achieve it yet but I'll look into it.
Cheers,
Andrew
Patch has been applied to Dev and I'll tag a new release shortly.
Patch Attached to add checkbox and select with asset code for linking to alternate image style to image fields.
If anyone is following this issue, give it a spin. I'll apply it to the DEV and then tag a new release within the week.
Cheers,
Andrew
awasson → created an issue.
Updating the Issue Summary.
@Nathan Tsai is correct, this is an issue with Drupal 8 and Drupal 9. I will create a new issue specific to the D8, 9, 10 version.
It may be that the API needs to be updated per Twitter's changes last fall but that's not the major issue. The big issue is that embedded twitter feeds have been disabled by twitter. They did it last weekend. Even Twitter's own website shows a generic "Nothing to see here" message.
This is the reaction over at the Twitter Community:
https://twittercommunity.com/t/again-list-widget-says-nothing-to-see-her...
Thanks @shivam_tiwari ,
I think the module and library is too broken to do anything with now. It will need a full ground up rebuild to work with the way Instagram authenticates.
Cheers,
Andrew
@TR,
The patch definitely works which is great (thanks @poker10) but is there any reason a new release hasn't been tagged? For now I'll use the Dev but it's a production site on PHP 8.2 so I'd rather use stable releases.
Cheers,
Andrew
@v.koval,
If that works, that would be great. Can you come up with a patch so we can test it out?
Cheers,
Andrew
Just moving this to the 2.0.x branch. I haven't looked into this yet but I'll have a look as time permits.
Cheers,
Andrew
Just moving this to the 2.0.x branch.
Hi @SirClickALot,
Not yet but now that I've moved it to the 2.0.x branch, I'll see what I can do.
Cheers,
Andrew
@MegaphoneJon,
Yes, I have a form for membership applications and in one membership category a single checkbox is optional.
Prior to applying the changes at https://github.com/civicrm/civicrm-core/pull/23305/files it would fail 10/10 times. I manually added the changes to my copy of the site and the error has not shown up since. It is absolutely necessary.
Cheers,
Andrew
Hi there,
Thanks for your interest in helping with the Slimbox2 module. I'm closing this as outdated as I have overhauled the code extensively and the issues in the report are no longer relevant.
Cheers,
Andrew
Thanks for your interest in the Slimbox2 module.
This issue is being closed as outdated. A new new README.md file has been written and the changes are too extensive to use this patch.
Cheers,
Andrew
Tested and looks good. I'll tag a new release with these changes shortly.
Cheers,
Andrew
@samit.310@gmail.com,
Thanks for the patch.
I'll review this and update as soon as I have done so.
Cheers,
Andrew
Any thoughts on when or if this will be rolled to the Stable or Dev versions of Admin Menu?
@joelpittet,
Thanks for that. I've cloned the 3.0 Dev and tested it locally. It seems to work well in my Mac OS Ventura 13.2 environment. In my latest Basic themes, I've been using "node-sass": "^5.0" and on my arm64 (M2 Chip) Mac and found that I had to unlink the latest Node and use node 14. I'm not sure if that's the same case with Sass. I see that you've also switched out node-sass for "sass": "^1.0.0".
Anyway npm install installed without any issues and npm run watch:all appears to work well.
Cheers,
Andrew
Ran into this issue this afternoon myself.
This patch is good to go.
@MegaphoneJon,
I just wanted to comment that I have a D7/CiviCRM 5.57.0 website (with Webform CiviCRM) that we recently pushed to Drupal 8.1 and have experienced WSOD on submissions where the culprit appears to be a single checkbox that is linked to a CiviCRM text checkbox field.
I applied the patch from your PR and it appears to have resolved the issue: https://github.com/civicrm/civicrm-core/pull/23305/files
Cheers,
Andrew
@ joelpittet, Is this using the package.json file you shared with us a few years ago?
This is the version I've been using with a modded version of Basic for D9 and aside from not creating map.js, it's super light and fast.
{
"name": "basic",
"version": "2.0.0",
"description": "BASIC Theme Version 2",
"license": "MIT",
"scripts": {
"sass": "node-sass --recursive --source-map true --output-style expanded --output css sass",
"autoprefixer": "postcss --no-map -u autoprefixer --autoprefixer.browsers -r css/*/*.css",
"build:css": "npm run sass && npm run autoprefixer",
"build:images": "imagemin images/source/*.{png,jpg,gif,svg} -o images/optimized",
"uglify:js": "uglifyjs js/source/*.js -m -c -o js/build/scripts.js",
"watch:css": "onchange 'sass/**/*.scss' -- npm run build:css",
"watch:img": "onchange 'images/source/*' -- npm run build:images",
"watch:js": "onchange 'js/source/*.js' -- npm run uglify:js",
"watch:all": "concurrently --kill-others 'npm run watch:css' 'npm run watch:js' 'npm run watch:img'"
},
"dependencies": {
"bourbon": "^5.0.0-beta.8",
"bourbon-neat": "^2.1.0",
"autoprefixer": "^9.7.6",
"concurrently": "^4.1.1",
"node-sass": "^4.13.1",
"uglify-js": "^3.9.1",
"imagemin-cli": "^5.1.0",
"onchange": "^6.0.0",
"postcss-cli": "^6.1.3"
},
"browserslist": [
"> 1%"
]
}