🇺🇸United States @aharown07

To set/change the admin theme (replacing 'claro' or 'olivero' below with the machine name of the theme of your choice)

drush config-set system.theme admin claro

To set/change the site default

drush config-set system.theme default olivero

This works as of Drupal 10.2.5 with Drush 12.5.1.0.

If you want Drupal 10 on a PC or Mac, the process is basically this:

1. Set up a local development environment (For Windows, I've used Docker and DDEV: https://ddev.readthedocs.io/en/latest/users/install/ddev-installation/#w...)
2. Install Composer and Drush
3. (Verify that your local environment provides a database for your Drupal site. If not, use the local environment's tools to create that. In the case of DDEV, it's done for you.)
4. Use Composer to install the Drupal files and folders
5. Run the php install script to complete the installation (go to https://<url your local dev environment specifies>  or, if necessary go to https://<url your local dev environment specifies>/install.php)

Personally I find it easier to just work on a real server on the web/cloud, but that does introduce a set of security concerns you don't have if you develop on your local desktop.

Webform?
It's been a while since I worked on this issue--or used Webform module, but the idea occurs to me that presenting non-admin themed form to users for making their own polls might be a good Webform use case.

It's still not clear to me, though, why the checkbox to use the default theme shouldn't just work as expected.

(If it helps, the use case here is a forum where users not only post comments but create nodes of the allowed type. They are also allowed to create polls to add to their nodes.)

tawellman's edits to rules_flag.module (for me ver 1.0.3) are also working on my sites.

I also don't know how to roll patches the git way. I see instructions here → and here → , but I currently manage a single public website and one dev version... so it has not made sense to learn Git just for that.
... likewise for interdiff → and drupalorg-cli.

But here's an old fashioned diff patch.

I am seeing this error also since moving from Drupal 9.5 to 10.

My flags and rules were working perfectly in 9.5 but now one flag has to be clicked twice, and another goes to an error page "The website encountered an unexpected error. Please try again later." Then clicking the flag appears to not execute the rule.

As of Drupal 10 and Drush 12, the Drush Launcher is no longer recommended.

Details here on how to remove Drush Launcher and run your Drush locally per project: https://sebastix.nl/blog/upgrade-to-drush-12/

The contrib version of 'Stable' theme also seems to work. I haven't completed an upgrade to D10 to see how that goes, but Upgrade Progress report is happy.

I don't know if adding this comment helps, but... I would also like to see this go live for D10.

The project page for contrib stable currently says you can't install it with composer.

Yes, please. The theme is not Drupal 10 compatible if it has a dependency on stable.

4.0 working for me in my D10 test site.

Making some 9x>10 plans and I need to try to clarify the process a bit. Or confirm what I'm thinking.

Is it something like disable 2.0, upgrade the site to D10, then composer require the 2.1?
Or... since the "!... " exclusions are stored in each block config, just uninstall the 2.0, then after upgrading the site, reinstall 2.1? I'm thinking that's the way to go.

This, then:
* Disable, then composer remove the 2.0 version
* Complete site upgrade to D10
* Composer require the 2.1 beta version.
Done.

+1. Appreciate the module but need the D10.

I had the same problem. It's not obvious that you have to check boxes then find a button. I kept refreshing the page to rescan, with no change.

I did some fruitless googling before landing here. So I'm adding this for some keywords: manually rescan, force a scan, upgrade status rescan.

Got it.
I misunderstood the scope of the 'CKEditor support' checkbox in the config.
In #9 above, the problem does not occur if:

* Install the (deprecated) CKEditor4 module
* Uninstall CKEditor 5
* Switch the 'Basic HTML' text format editor to CKEditor 4
* Re-enable 'CKEditor support' checkbox in the Quote module config.

For some reason, on my live 9.5.11 site, the Quote selected link is not working, even with CKEditor 4 set for the text format. So there must be a conflict with some other module or something in the theme.

Also, on the test site I used in #9, I just renabled CKEditor5 and set it as the editor for the Full HTML text format. This did not break 'Quote selected' for the Basic HTML editor using CKEditor4. So probably that second bullet above is not relevant.

Since I'm mostly working on migration to D10, I'm mostly interested now in getting 'Quote selected' working with CKEditor5. Users have told me they really like that feature, and I like it as well. (If I had the skills to contribute some code for CKE5 compatibility, I would do it for sure.)

I did a fresh Drupal 10 install, standard profile.
Installed and enabled Quote module as above.

"Enable for CKEditor" is disabled on the Quote module settings form, as is 'Quote and reply selected.'

The enabled links again fail to work, though in this case, that's expected since the module is not enabled for CKEditor.
If I set the text editor to 'none' (the only other option available in D10 if not using CKEditor), the quote links work, though the results are raw html.
For example...

<blockquote><strong>d10dev wrote:</strong> This is the body of test article 1.

Some more text.

A bit of formatting and italics and such.</blockquote><p><br/></p>

So maybe this is a separate issue. Without some additional configuration steps, it does not appear to be possible at the moment to enable 3.0.2 for CKEditor in Drupal 10.1.2.

I did a fresh install. The problem still occurs.

Steps to reproduce:

Install a new Drupal 9.5.10 codebase in a test folder: composer create-project drupal/recommended-project:^9.5 test
Install Drupal 9.5.10 using the 'Standard' profile.
Install Quote module composer require drupal/quote and enable
At /admin/config/content/quote enable the Article content type.

Create a test article.
Add a test comment.
Select some text in the test comment.
On using the Quote module links on the test comment...

• Click quote selected link: nothing happens.
• Click quote all: nothing happens
• Click reply and quote all: works as expected

Two errors occur in the log, but only when executing 'Reply and quote all.' There are no errors in the Drupal log for 'quote selected' or 'quote all' because nothing happens on the back end.

No errors are showing in the browser console.

Tested browsers: Edge, Chrome, Firefox

Test system info:
PHP version: 8.1.22
Web server: nginx 1.18.0
MySQL: Ver 8.0.34-0ubuntu0.22.04.1

Forgot to mention that I already tried that.
Just gave it another test though. Disable JS cache, flush caches, flush browser cache: same result.

Yes. On click... Uncaught Error: Syntax error, unrecognized expression: ##
Here's the whole dump. I do not really know what any of this means.

Uncaught Error: Syntax error, unrecognized expression: ##
    at se.error (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:13911)
    at se.tokenize (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:21922)
    at se.select (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:22749)
    at Function.se [as find] (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:7196)
    at E.fn.init.find (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:25319)
    at new E.fn.init (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:25808)
    at E (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:1051)
    at HTMLAnchorElement.handleFragmentLinkClickOrHashChange (js_vHpQSPK6DLv5mdZ1Zo1ftvC16jeAL1Z9OC_mZWID2dI.js:305:21)
    at HTMLAnchorElement.<anonymous> (js_v5UIu0v1tn9EUi1BL-qTK9PExxraHyDNwfMf2qO1aOY.js:140:21)
    at HTMLDocument.dispatch (js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2:43336)
se.error @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
se.tokenize @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
se.select @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
se @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
find @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
E.fn.init @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
E @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
handleFragmentLinkClickOrHashChange @ js_vHpQSPK6DLv5mdZ1Zo1ftvC16jeAL1Z9OC_mZWID2dI.js:305
(anonymous) @ js_v5UIu0v1tn9EUi1BL-qTK9PExxraHyDNwfMf2qO1aOY.js:140
dispatch @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2
y.handle @ js_Lw8Eex-_h9s3YWHkSTsC-5uusyLUgV2ahMRbERVGoYs.js:2

Took a look at another test site where I have 3.0.1 version of the module installed.
The module works as expected there.
The links also look the same (root/path##), so that's apparently not relevant.
This other test site has all the same other modules I believe. It is on Drupal 9.5.4 though, if that matters.

Rewording the issue title to be more vague but less inaccurate.

aharown07 → created an issue.

Much appreciated.

I have applied the patch to a dev site with good success in results so far, with Bigram enabled.
The test site has just over 23,000 items indexed.

Seems to work really well with facets and everything as expected.

To echo ressa, thanks for your work on this. I hope it makes it into a future release. Also makes sense to me to enable by default in installs.

@awolfey
Clever! I like it. I'm not sure I'm going to use it, but you just made me smarter.

I am able reproduce in a new install.

TLDR: disabling the "Replies to my comment" checkbox at admin/config/people/comment_notify causes the comment form to fail to load on nodes with the custom comment type.

Steps to reproduce:
Standard install of 9.5.7
Create custom comment type
On the Basic page content type, add a new field for comments of the custom type
Install comment_notify via composer and enable (and token comes along as a requirement)
At admin/config/people/comment_notify, check the box for the custom comment type
Create test nodes for Article and Basic page
Verify that comment form loads normally for both the default comment tupe (on Article) and the custom type (on Page)
Return to admin/config/people/comment_notify and uncheck "Replies to my comment"
Return to test node of the Basic Page type: the comment form fails to load

I am not able to reproduce the issue on a new 9.5.7 'standard' install, everything default, + this module and 1 custom comment type. There may be a conflict with some other module. Planning to test further.

Thanks for the patch!
Working perfectly on my build. 8.x-1.16

I'm not sure what the rules are for marking an issue RTBC, so... will leave as is, but would love to see this go into next release so I don't have to keep patching it. Also, this seems like a bug to me. Shouldn't the module respect the 'Use the administration theme when editing or creating content' checkbox setting?

For others who have seen the 'script in a footer block' method stop working, a solution that is working for me is the Header and Footer Scripts module → . Put the Reftagger code in the footer field.
Flush caches. If you have javascript aggregation enabled, turn it off, save, then turn it back on again.
It works.

aharown07 → created an issue.

Ubuntu 22.04 is still installing 8.1.2 from the default repository.

It's not clear to me from all the above how to upgrade that to anything higher without adding a ppa. Can anyone elaborate? 

apt install results in php 8.1.2.

apt upgrade sees the php as up to date.

After more testing: some accounts see the form and some don't. User1 seems to be consistently not getting the form load.
Other accounts... I can't see any pattern to it after a lot of messing with roles and permissions, etc.
Two accounts with identical permissions get different results.

Disclaimer: this is an odd one. I'm not 100% sure I have the steps to reproduce right.

At the moment, it appears I had some fact confused before, because what I observe is:
* Custom content type node created by non-user1, custom comment type, with notify enabled:
- non-user1 sees the comment form normally, along with the 'notify me when...' checkbox
- user1 does not get the comment form or the 'notify me when...' checkbox
- (user1 sees comment form normally on nodes with non-custom comment type, along with the 'notify me...' checkbox)

* Custom content type node created by user1, custom comment type, with notify enabled:
- non-user1 sees the comment form normally, along with the notify checkbox
- user 1 does not get the comment form or notify checkbox
- (user 1 sees comment form normally on nodes with non-custom comment type, as well as the 'notify me' checkbox)

Not tested on a fresh Drupal 9 build.

Tested for conflicts with permissions modules: uninstalled Field Permissions module, Node View Permissions module, View Unpublished module rebuilt permissions. No observable change.

Also tested: switching theme to Olivero. The problem exists there as well.

Probably worth noting: when I look at the page code for a page lacking the comment form, I do see "notify me when..." string in the code... but so far I can't make any sense of it.

aharown07 → created an issue.

aharown07 → created an issue.

Flag anonymous seems to be a good solution to this problem in my testing.
@Murz, thanks for the tip.

aharown07 → created an issue.

I don't know how to code a "return to where you were when you clicked /poll/add" route.

What I've done as a workaround may be useful to someone (replacing WHATEVER as needed)

• Step one: create new route in poll.routing.yml

poll.poll_WHATEVER:
	  path: '/WHATEVER'
	  defaults:
	    _title: 'WHATEVER'

• Step two: change route name in poll/src/Form/PollForm.php to use the new route instead of poll.poll_list
This is currently line 70. Looks like this: $form_state->setRedirect('poll.poll_list');

Of course, this approach requires re-hacking after any update to poll module.

I ended up going back to #99 because I had a couple of views where I couldn't use the target ID method in #109 (or maybe more accurately, had a couple of views where I couldn't figure out how to use it). In any case there are tradeoffs: with #109, you have to set this up for each view. With #99, you solve the problem with all of them.
It turned out I have a pretty large number of views with entity reference relationships causing duplicate rows.
I also no longer see any errors with that patch in place.

Seems like this qualifies for RTBC at this point?

I am no longer testing Private Message module. All I can say with certainty is that I was still encountering the problem in 3.0 beta 2 back in November.

aharown07 → created an issue.

aharown07 → created an issue.