@cestmoi

Thank you @himanshu_jhaloya but this patch while addressed the required select on the block config page, it's causing the below error on trying to access any page that has the block:

Error: Call to undefined method
Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsButtonsWidget::setAvailableNewsletterIds() in Drupal\simplenews\Form\SubscriptionsBlockForm->form() (line 131 of ..... \web\modules\contrib\simplenews\src\Form\SubscriptionsBlockForm.php).

I confirm patch #25 works well.

I applied patch #25 on Drupal `10.3.2` / simple_popup_blocks `8.x-3.1` and the issue is gone.
The `Choose the identifier` is `Drupal Block` and the popup is working for admin and anonymous users. The original block is hidden in the theme region and only shows in the popup.

Adjusted the issue text to show what really needs to be done.

It turned out that I had to select at least one newsletter under 'Visible Newsletters' on the block config page. Now everything seems to be functioning as expected. I hope this helps someone who comes across such an issue.

Perhaps it's better if the block wouldn't save without selecting a newsletter or at least a warning message is shown on the block config page.

cestmoi → created an issue.

I wonder if/how you ended up doing that with Drupal.

I've been researching this very issue trying to have a Drupal alternative for the Wordpress/WooCommerce combo but it seems there is no one solution available yet! My case is for dropshipping mainly and none of the commerce modules seems to ever be thinking about implementing such now-very-popular functionality.

It sucks that I have to go for `Wordpress/WooCommerce` just to have that!

cestmoi → created an issue.

I confirm this patch seems to have fixed it, Thank you @sl27257
Yes, I already had some AJAX headaches with Webform but apart from the multilingual factor which I have yet to test (fingers crossed).

Thank you @Peacog. I managed to finally import it and make it work after figuring out that I have to add the translations directly in the yml file rather than searching for it in Configuration Translation, User Interface Translation, or in the Content Type.

Looks good thanks but what I meant was on the project page → itself and/or elsewhere (`readme.md`, `.info`) .

6 years later and this issue is till there!

I tried to make the fields (title and description) translatable in my custom theme templates but could only make {{ description }} work by adding the `straptags` filter first and then `|t` ! For the title I had to `title['#markup']|t` .

I'm not sure if this is a safe practice and don't like having to use the `striptags` filter so I tried the solution #4 🐛 translate field_group description for detail & fieldset Closed: works as designed suggested by @Peacog but am not that familiar with using config `yml` for translation as suggested.

It would be so nice if you can give full and clear detailed instructions on how to :

In the meantime you have to provide the configuration translation yourself by creating a file in your config/sync/language/LANGUAGE directory. The easiest way to do it is to find the config file for your default language, copy it to the directory for the language you are translating to, and remove everything except for the field group settings. The file will have the format core.entity_view_display.ENTITY_ID.VIEW_MODE_ID.yml

In my case, I did a full config export and I copied the `core.entity_view_display.node.book.full.yml` then renamed it to `core.entity_view_display.field_group.yml`, kept only the parts for field_group in it and translated labels and descriptions in it, and add it to the newly created `config/sync/language/LANGUAGE directory` but couldn't see any effect of that! I then tried copying the content and paste into single import at /admin/config/development/configuration/single/import but wasn't sure which config type I should choose and failed with all I tried.

Since this issue may take few more years to be solved by core as far as I understand it's why "Closed (works as designed)" then there should be a clear step by step agreed temporary solution.

cestmoi → created an issue.

Thank you this seems to have solved it. I tested it with no more issues.

And yet years later and this "simple" issue is still not officially solved. I am translating a site and knocking my head off the wall once with an "ago" instance that I cannot find where-to anywhere and now with this field_group thing, just to name a few. It seems Drupal still has a long way to go to say it's a reasonably "fully" ready multilingual CMS.

Is the /fr the language selector (French) or is that a sub directory?

You probably have the answer by now but to confirm, it's the language selector not sub dir.
Yes it seems one wouldn't have this issue if not on a multilingual site and happened to test it.

Thank you @sl27257
This is the first time I use the module but I jut tested it on SimplyTest.me with Drupal 9.5.11 and it seems to work fine without such issues.

cestmoi → created an issue.

cestmoi → created an issue.

I just installed and testing the module and got this issue too.
I'm having this same issue and I have no such conflict with another Flag module.
Only admin can access the block (no roles restricted).
Flag Bookmark and Unflag Bookmark permissions are given to authenticated users.
Same even if I give users permission to See Other's Bookmarks just to test.

I got this error when I enabled the module via `drush` instead of admin UI on Drupal 10.1.6 . I uninstalled it `drush pmu pathauto` and then enabled it via admin UI and all went well.

Patch #72 caused these errors on saving default `Word Document` at /admin/config/content/entityprint

TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 263 of
 pathto\web\core\lib\Drupal\Core\Entity\EntityStorageBase.php).

Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 278 of pathto\web\core\lib\Drupal\Core\Entity\EntityStorageBase.php).

form Error The submitted value 1 in the Word Document element is not allowed.

Drupal 10.1.2
entity_print 8.x-2.x-dev
php 8.1.10

I got this same error after composer installing latest stable version (2.0.8) and enabling via `Drush`. I had to disable it via drush and re-enable it via admin UI to make it work. I am on Drupal 10.1.2, PHP 8.1.10.

cestmoi → created an issue.

Same patch, just renamed the file per known standards.

I think this patch is ready for RTBC. Please test and report so we have a D10 release sooner.

With regards to the module install/enable via Drush vs UI, I think since the module cannot be required with Composer due to absence of a compatible release and it has to be added manually, installing it via Drush would cause errors such as the one below because Drush uses the Composer autoloader to load classes, and if the module is not listed in the composer.json file, its classes won't be found. That's why it installs fine via admin UI but not via Drush.

Drupal\Component\Plugin\Exception\PluginException: Plugin (filter_hashtags) instance class "Drupal\hashtags\Plugin\Filter\FilterHashtags" does not exist. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 97 of pathToDrupal-10\web\core\lib\Drupal\Component\Plugin\Factory\DefaultFactory.php).

That's why until there is a compatible release that can be required with Composer, the only way to enable the module is via admin UI, I understand.

I tried to `Composer require` it with the patch following this (D8/D9) tutorial but it didn't work.

@keshav.k thank you but that issue is for D9 not D10 and while D9 is near its EOL shouldn't efforts be on a stable D10 version ? This issue is mainly for D10 compatibility while that issue has no mention of D10. I also added fixes for issues that weren't tackled in that other issue. Anyways, I just hope this module gets the attention it needs esp. that its latest release is only D8 compatible.

None of the tips seems to apply to Drupal 10. Any ?

@ Maintainer(s), this is my first such patch so kindly correct me where applicable.

I just created a new issue with a complete patch with changes against the latest official release → . Please check and test it from here 📌 Drupal 10 Compatible Version Needs review .

cestmoi → created an issue.

@alex.amtr I managed to make it work on Drupal 10.1.1 by just editing the .info.yml file with core_version_requirement: ^8.8 || ^9 || ^10 but you need to install it via UI not via Drush as this would break your site.

Make sure to have a DB backup before installing it as this was the only way I could restore and repeat the install via UI. There are still few bugs to be fixed by someone more knowledgeable but the basic function of the module is working for me (creating the hashtag term and link).

I shall create a new issue for this and my experience so far and hopefully be able to create a patch for D10 compatibility if had time for it. If anyone can do that sooner please do.

The information on overriding templates not only applies to Drupal core templates but to contributed modules templates as well.

In my case, I only had to move the "Footnotes filter" to be placed before the enabled "Convert URLs into links" filter at admin/config/content/formats/manage/full_html

- Drupal 10.1.1
- Footnotes 3.0.1 (with patches for D10 compatibility, CKE5, and Fakeobjects dependency removal)

@catch thank you. For some reason installing the footnotes module after applying all 3 patches (D10, CKE5, and Fakeobjects) threw a php error when I did the install via drush but all went fine when I installed the module via drupal admin UI. I have the core CKeditor5 enabled, CKE4 and Fakeobjects modules removed, and footnotes filter enabled and it seems to be working as expected per my testing so far, and no errors.

@catch thanks, I tried this and it didn't work and I guess it's because I have core CKE5 enabled and I don't want to uninstall it. This also doesn't address what should be the main issue worked on for footnotes i.e. a D10 compatible footnotes module that takes into account that fakeobjetcs is dependent on cke4 when core D10 already has cke5 with fakeojects plugin already there.
Different issues each working on one aspect but no one is taking ALL these considerations together especially now that D9 is near its EOL!

@Franz-m how did that ✨ Support for ckeditor 5 Fixed end up for you ?
Do you have ckeditor4 installed despite the core ck5 being there :-?
This whole chaos/dilemma about D10/Ckeditor5 .. fakeobjects/ck4 seems to not be addressed by anyone yet so we get a working D10 compatible version without the need for the ckedtior4 anymore.

This issue is still there on latest versions (Drupal 10.1.1 and Webform 6.2.0-beta6 ) - I could replicate it on Simplytest.me (using the webform/example_style_guide/test ).

Only happens when ajax is enabled. In this case, the stars only show after refreshing the page. It also existed on prior versions (D9+) for me

For anyone that might still wonder. As one can see in each module description:

The Mentions module → "offers Twitter like functionality, recording all references to a user's username - using the [@username] or [@#uid] filter format" . I.e. this module is about tagging only other drupal "users".

While the Linkit module → "provides an autocomplete interface for internal and external linking in rich-text editors". I.e. this module is all about inserting a link to an already existing url, internal or external.

In comparison to the two above, this hashtag module creates a taxonomy term from any word that's preceded by a "#" sign and hyperlink the hashtaged word to the taxonomy term.

@ramonvasconcelos @bruno.bicudo I'm not sure any patch shared here has any fix for the help page issue. I tested the version posted by @cuman (#14) and while all worked as expected, the help page gave an error still.

I just noticed this issue and I think it should be a configurable option setting instead of "fixing" it.

Thanks. I understand and appreciate all the support and the work and I do my best to help with all I can within my abilities (contributing to Drupal) but isn't such a bug a priority though regardless! In fact, all my questions here are for a voluntary work and I personally couldn't afford any extra financial burden on top of it.

Anyways, thanks for responding and letting know why the bug is ignored. If there is anything else I can help with apart from money, please let me know.

sorry for the bump but I wonder if there is any process !

Thanks @cilefen
The issue can be seen on the Image Select element in the example_style_guide webform after changing the images paths to point to private dir as per below example.
Below is the relevant part ( plus a separate issue re rating stars) from the example form. Both the example form and this mini form copied from it and just edited the images paths.

introduction:
  '#markup': '<p>Below is taken form the example_style_guide webform and all the webform settings are left as is. The issue: Images show fine to admin but not to permitted users when images in private dir (Default file download is set to private in File System config), user gets Access Denied when trying to open the image in a new tab, images src look correct in the source code. A seperate issue is the "rating stars" aren''t showing (for anyone) on preview (regardless of user privilege)</p>'
advanced_elements:
  '#type': details
  '#title': 'Advanced elements'
  '#open': true
  webform_image_select:
    '#type': image_select
    '#title': 'Image select'
    '#images':
      kitten_1:
        text: 'Cute Kitten 1'
        src: /system/files/webform/imagetest/kitten1.jpg
      kitten_2:
        text: 'Cute Kitten 2'
        src: /system/files/webform/imagetest/kitten2.jpg
      kitten_3:
        text: 'Cute Kitten 3'
        src: /system/files/webform/imagetest/kitten3.jpg
    '#show_label': true
  webform_rating:
    '#type': rating
    '#title': Rating

cestmoi → created an issue.

I've been having similar issue with private files. I have a Webform with images element, the images urls in private files dir and show fine for admins but not for authenticated users when filling the form. This whole drupal private files thing seems to still be a dilemma unsolved for many, or at least lacking clear thorough documentation

Hi everyone. I see there are some folks still having this same error and wanted to share what I did.

I had same issue although I do see the config file mentioned by @jrockowitz in web\modules\contrib\webform\config\install
I'm not using the option "sex" in any form and it's only used, it seems, in some example forms where the "Sex" form is empty.

I ended up adding the option (sex) manually at admin/structure/webform/options/manage?search=&category%20=Demographic
That solved the problem and no error seems to be logged anymore, and the options (Male, Female) now show in the Example forms.

I hope this helps

cestmoi → created an issue.

cestmoi → created an issue.

@Berdir

"one is the UUID for the role, the other for the user, there's no reason to and you shouldn't reuse it like that."

I also, after updating from 8.6.1 to 8.8.6, had same issue and seem to have fixed it by creating the user 0 row in the DB with :

INSERT INTO users (uid, langcode, uuid) VALUES (0, "en", "");

No error now but the user 0 has no uuid. Is it safe to leave it without a uuid ? and if not then how to create one ?

Another weird observation, I checked the DB of the original Drupal 8.6.1 and found it missing the user 0 too but doesn't have the error of this OP !

Thanks