🇨🇦Canada @earthangelconsulting

earthangelconsulting → created an issue.

for what it's worth... i tried the patch in #7 applied against version 5.2 of the module, in a simple test case, and it worked exactly as expected! awesome! i hope this can get incorporated into a release soon.

(otherwise that checkbox "Check view access for this field" that appears for webform fields in Views is very misleading ;-) )

@catch ... sure i can try, once my current workload lightens up a tiny bit. this error i had (both on DDEV and server) was with a fairly complex site, so figuring out which contrib module starts off the error will take a bit of experimenting. it's definitely necessary though. i will keep you posted.

thanks for all these patches, awesome people. i will give this a shot.

has anyone tried this on D10.2 yet? or just D10.1 ?

(needless to say... "+1 for a new release for Drupal 10.")

to confirm, we also have this bug, Drupal 10.2.4, happened both on DDEV and on the web server, no extra caching modules (Varnish, Cloudflare, LiteSpeed, etc.) in use. the only way to prevent it from causing issues on the front end (sometimes the aggregated css or js files are broken, and this causes javascript errors, in our case) is to turn site aggregation off entirely.

note: i also posted to webforms, not being sure where the problem was. the webforms maintainers believe the problem is on their end, see https://www.drupal.org/project/webform/issues/3436030#comment-15520637 🐛 webform CAPTCHA elements not respecting the CAPTCHA whitelisting of IP addresses Needs review

i think that you can close this ticket!

thanks @cliefen! amazing fast response there!

my apologies for creating two issues, but i honestly wasn't sure if the problem was in some API that the Captcha module was providing, or in something that Webforms was doing, so i wanted maintainers of both modules to see the problem.

that means i can probably just close that issue in the Captcha issues queue then.

i look forward to trying your MR to see if it works for me.

thank you @joseph.olstad :-)

@joseph.olstad what was the patch, and what version were you using before patching? i need to see if this applies to my situation.

earthangelconsulting → created an issue.

earthangelconsulting → created an issue.

we are still in the final testing stages, but it seems that #41 (using symfony_mailer_lite → ) worked really well for us. all existing mail templates, etc. set up for swiftmailer are working fine. the emails marked as HTML (eg: in webforms) are still being delivered as HTML with no obvious changes.

that being said, we actually have Mailchimp Transactional mailer set as the formatter and the sender, in the mailsystem page /admin/config/system/mailsystem ... however i am still quite sure that symfony_mailer_lite is doing the trick because:

- in our DDEV development sites, which are not using mailchimp, emails are still being sent correctly

- if i understand this, then regardless of what you have set as your mailsystem, swiftmailer is what was providing hook_mail() and hook_mail_alter(), correct? and symfony_mailer does not provide those, though symfony_mailer_lite does? if that is correct, then it is definitely working, as some things that are being set in hook_mail() calls by various contrib modules are still working properly.

i definitely suggest trying this approach. just install symfony_mailer_lite and it will take over (once the mailsystem page is pointing to it, see below) and then uninstall swiftmailer once you are sure it's working. if you are already in an upgrade situation where swiftmailer is already gone, that's fine, just make sure you check your backup sites, etc. and get any config needed for setting up symfony_mailer_lite (eg: SMTP ports... see below) unless you are just using "php native sendmail" (which has no config details, not within Drupal anyhow).

aside from installing it, you will need to:

- set symfony_mailer_lite as your Formatter and Sender, on the mailsystem page /admin/config/system/mailsystem (kind of obvious but i am writing this to help intermediate level devs, as well as experts ;-)

- configure symfony_mailer_lite at /admin/config/system/symfony-mailer-lite/transport and /admin/config/symfony-mailer-lite/message-settings and test it at /admin/config/system/symfony-mailer-lite/test if using "native php sendmail" to send, it should already be configured on install. if you are using Sendmail or SMTP or other methods, you will need to plug in the hostnames, port numbers, etc. (unless you find that symfony_mailer_lite has copied them correctly from your swiftmailer setup, which it might!) any other issues... refer to https://www.drupal.org/project/symfony_mailer_lite →

i apologize for any uncertainty about some of the details in the above, this was done very quickly and when most of the way through a very complicated upgrade... though i can safely say that in this case, symfony_mailer_lite saved our butts. thanks maintainers for that sweet module!

#7 💬 The "node_type" plugin does not exist - upgrade from D9 to D10 Closed: cannot reproduce was very helpful (if you are using pathauto, see this issue: https://www.drupal.org/project/pathauto/issues/2925169 💬 PluginNotFoundException: The "node_type" plugin does not exist Fixed and try #23 💬 PluginNotFoundException: The "node_type" plugin does not exist Fixed )

#23 worked for me too. thanks!

confirmed!  after five hours of trying i finally got composer to build without error... and  removal of core-dev was the final step needed!

it is extremely important in some scenarios, at least in mine (D9.5.10 to D10.0.11)

i will spread the word that this is great advice.   thanks, original poster!

can confirm, #13 worked for me!

(note: the following may help others, by making it more explicit, it is not intended as an alternate solution or anything)

your error might be different but similar, depending on the order you updated the modules in.

when i did this:

composer require 'drupal/better_exposed_filters:^6.0'

it only updated to 6.0.2, not 6.0.3, since jquery_ui_slider wasn't updated yet.

then, when i did this:

composer require 'drupal/jquery_ui_slider:^2.0'

i got this error from composer:

  Problem 1
    - Root composer.json requires drupal/jquery_ui_slider ^2.0, found drupal/jquery_ui_slider[dev-2.x, 2.0.0, 2.x-dev] but these were not loaded, likely because it conflicts with another require.
  Problem 2
    - drupal/better_exposed_filters is locked to version 6.0.2 and an update of this package was not requested.
    - drupal/better_exposed_filters 6.0.2 requires drupal/jquery_ui_slider ^1.1 -> found drupal/jquery_ui_slider[dev-1.x, 1.1.0, 1.x-dev (alias of dev-1.x)] but it conflicts with your root composer.json require (^2.0).

(as i said, if you tried those updates in the opposite order, you would probably get a different message but similar to above.)

the solution, as #13 says, is simple, just do them at the same time:

composer require drupal/better_exposed_filters:~6.0.3 drupal/jquery_ui_slider:~2.0.0 --with-all-dependencies

thanks @bburg!

ps: if you only have jquery_ui_slider installed because it's a "requirement" of better_exposed_filters, whether you are using controls of that type or not, then the patch that is mentioned in #13 isn't needed.

otherwise... see #13 :-)

@artem_sylchuk - thank you for this detailed reply!

the client is still deliberating as to whether they use this module enough to spend the time upgrading it for D10, so i might not be able to provide you any useful feedback.

if i do end up proceeding with this, i will definitely let you know what i find!

re:#13 awesome! :-) thanks!

re: #11 that's great to hear!

that error i was getting (see #8)

[ERROR] You have requested a non-existent parameter "drupal_rector_notices_as_comments"

i already found the fix, by looking at the rector-config-template.php file provided by the upgrade_rector module.

rector.php should contain this line:

$parameters->set('drupal_rector_notices_as_comments', true);

i hope this can make it into the next release too :-)

glad to hear it ! great project!

you just need to change your contentimport.info.yml file to show D10, for composer's benefit :-)

earthangelconsulting → created an issue.

question: does this mean that one could use 8.x with D10, providing they applied any patches listed in this issue, and/or fixed any remaining bugs like "The module twig_temp does not exist" (#8 above)?

i know that it is recommended to use 2.0.x for D10 but we have a client where all their custom code was written for the API provided in 8.x, and the programmers who did it say that upgrading that code to use Stripe 2.0.x instead would be an incredible amount of work.

therefore, we are considering the possibility of just doing the D10 fixes and remaining on 8.x, at least for the foreseeable future.

is this realistic? or is there some deep conceptual reason why this wouldn't work, or really should NOT be attempted?

I am confused about how there could be all these upgrades to various modules, inserted into issues queues with subject "Automated Drupal 10 compatibility fixes", and mention as being as done by Drupal Rector... and yet there currently isn't a version of https://github.com/palantirnet/drupal-rector that works with D10? can anyone explain this?

I am also curious about a D10 compatible release... any updates?

still, we are making progress here :-) thanks all!

well, it's interesting that duckydan and i keep getting different results, there must be something about their data that is different?

i am using the latest dev version, (i upgraded by doing this: composer require 'drupal/find_text:1.x-dev@dev' ) ... and now i get this error:

Message Error: Call to a member function hasField() on null in Drupal\find_text\Form\SearchForm->buildResultsTable() (line 247 of /var/www/html/web/modules/contrib/find_text/src/Form/SearchForm.php)

i tried what @duckydan suggested and it did not work for me, unfortunately.

i get a different error, in the same piece of code

Error: Call to a member function isPublished() on null in Drupal\find_text\Form\SearchForm->buildResultsTable() (line 247 of /var/www/html/web/modules/contrib/find_text/src/Form/SearchForm.php)

it seems that $node in the following line

if ($node->isPublished()) {

is null

i looked at the immediately surrounding code, to see if we could just add a conditional for that, but from what i could see it made no sense for $node to be null in any "normal" situation.

i am admitting defeat for now, hope someone else can figure this out!

thanks @duckydan, i will try that later today, if it works, you are my hero! :-)

also, the first time i tried this did not occur, but the second time, the log file also had multiple occurrences (about 20?) of this error:

Message Warning: Undefined property: stdClass::$revision_id in search_fields() (line 240 of xxx/web/modules/contrib/find_text/find_text.module)

earthangelconsulting → created an issue.

hi there. adding myself to this thread so that i get notification when this is fixed. needless to say, checking for D10 compatibility is a big need for many of us right now ;-)

i had the same problem as @paulsheldrake (the D10 set missing) but at the time i was actually trying to test code for D9.5 compatibility, not D10, so I just removed the references to D10 from the rector.php configuration file, and used the more granular rule sets:

    $rectorConfig->sets([
    	Drupal9SetList::DRUPAL_90,
    	Drupal9SetList::DRUPAL_91,
    	Drupal9SetList::DRUPAL_92,
    	Drupal9SetList::DRUPAL_93,    
    ]);

now i get a different error:

[ERROR] You have requested a non-existent parameter "drupal_rector_notices_as_comments"

is this related to the current issue, or the backward compatibility fixes at https://www.drupal.org/project/rector/issues/3350886 ✨ Add backward compatibility to Rector rules Needs review ?

if not i will start a new issue

apologies, previous post isn't using the naming convention for patches. this one should be.

something puzzling here: the patch from #10 makes sense, however when it was merged to the main branch for version 4.0.0, a conditional in that patch was left out! this did not make a difference on php7.4 as far as i can tell. however, running version 4.0.0 on php8.1 causes that original error "Password must not contain the username" to occur, for existing users.

i wrote this simple patch and it seems to have fixed the problem. can someone please verify? The automatic test didn't give an option to test against password_policy 4.0.0 which is what it was designed for.

foo_posting is the machine name of a node type
foo_specialform is the machine name of a custom form mode, for nodes of type foo_posting
foomodule is the module that handles this

this is in the src/FooController.php script, within foomodule: (note that this use case is for a path that calls a node/add form, using form mode foo_posting ... if you need to edit existing nodes, it would be a bit different)

namespace Drupal\foomodule\Controller;

use Drupal\Core\Controller\ControllerBase;
use Drupal\node\Entity\Node;

class FooController extends ControllerBase {

  /**
   * Function to call the Foo Posting form
   *
   * @return array
   *   A renderable array
   */
  public function postFoo() {
  
    $node = Node::create(array(
    'type' => 'foo_posting',
    ));
	
    $form = \Drupal::service('entity.form_builder')->getForm($node, 'foo_specialform');  
    
    return [
      'form' => $form
    ];
  }

}

this is in foomodule.routing.yml (nothing out of the ordinary here! )

foomodule.fooposting:
  path: '/foo-posting'
  defaults:
    _controller: 'Drupal\foomodule\Controller\FooController::postFoo'
    _title: 'Post an instance of Foo'
  requirements:
    _access: 'TRUE'

and this is part of foomodule.module

function foomodule_entity_type_build(array &$entity_types) {
  $entity_types['node']->setFormClass('foo_specialform', 'Drupal\node\NodeForm');
}

there are definitely other ways to do this, eg: https://www.webomelette.com/how-switch-out-entity-form-mode-dynamically-... https://www.drupal.org/docs/drupal-apis/entity-api/how-to-create-an-enti... → this is just one of them.

i just want to add some confirmation, for the benefit of those who have found this page while trying to use form modes from custom code (rather than anything to do with actual code changes to Core)

those modules form_mode_control and form_mode_manager may be very handy, but if you are just trying to generate a node form from php, with an alternate (but already defined) form mode for that node type, then ALL you need is what is mentioned in #13 ! thanks, @dench0 that was very helpful!

i tried this in Drupal 9.4.15 and it still works just fine :-)

I understand that Drupal is continuing to evolve but... has this issue actually not made it into a priority list anywhere? The first time I tried Layout Builder in Drupal 9, this problem seemed really obvious to me too!

this is not working for me, i am getting the same error as the original poster.

i am trying to run version 8.x-1.9 of this module, on Drupal 9.5.0, php 7.4.33, Drush 8.4.6
(8.x-1.x-dev is identical to 8.x-1.9 at this time)

here's the stack trace:

>drush dmu-upgrade registration_type
Indexing...done.
Use of undefined constant MENU_DEFAULT_LOCAL_TASK - assumed          [warning]
'MENU_DEFAULT_LOCAL_TASK' (this will throw an Error in a future
version of PHP) HookMenu.php(73) : eval()'d code:14
Use of undefined constant MENU_LOCAL_ACTION - assumed                [warning]
'MENU_LOCAL_ACTION' (this will throw an Error in a future version of
PHP) HookMenu.php(73) : eval()'d code:22
Use of undefined constant MENU_DEFAULT_LOCAL_TASK - assumed          [warning]
'MENU_DEFAULT_LOCAL_TASK' (this will throw an Error in a future
version of PHP) HookMenu.php(73) : eval()'d code:14
Use of undefined constant MENU_LOCAL_ACTION - assumed                [warning]
'MENU_LOCAL_ACTION' (this will throw an Error in a future version of
PHP) HookMenu.php(73) : eval()'d code:22
TypeError: Argument 2 passed to                                      [error]
Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory::create()
must be an instance of
Drupal\drupalmoduleupgrader\Routing\Drupal8\RouteWrapper, null given,
called in
/home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Links.php
on line 90 in
Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory->create()
(line 34 of
/home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Routing/LinkBinding/LinkBindingFactory.php)
#0
/home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Links.php(90):
Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory->create(Object(Drupal\drupalmoduleupgrader\Routing\Drupal7\RouteWrapper),
NULL)
#1
/home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/drupalmoduleupgrader.drush.inc(352):
Drupal\drupalmoduleupgrader\Plugin\DMU\Converter\Links->convert(Object(Drupal\drupalmoduleupgrader\Target))
#2 phar:///usr/local/bin/drush/includes/command.inc(422):
drush_drupalmoduleupgrader_dmu_upgrade('registration_ty...')
#3 phar:///usr/local/bin/drush/includes/command.inc(231):
_drush_invoke_hooks(Array, Array)
#4 phar:///usr/local/bin/drush/includes/command.inc(199):
drush_command('registration_ty...')
#5 phar:///usr/local/bin/drush/lib/Drush/Boot/BaseBoot.php(67):
drush_dispatch(Array)
#6 phar:///usr/local/bin/drush/includes/preflight.inc(67):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#7 phar:///usr/local/bin/drush/includes/startup.inc(465):
drush_main()
#8 phar:///usr/local/bin/drush/includes/startup.inc(369):
drush_run_main(false, '/', 'Phar detected. ...')
#9 phar:///usr/local/bin/drush/drush(114): drush_startup(Array)
#10 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#11 {main}.
TypeError: Argument 2 passed to Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory::create() must be an instance of Drupal\drupalmoduleupgrader\Routing\Drupal8\RouteWrapper, null given, called in /home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Links.php on line 90 in /home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Routing/LinkBinding/LinkBindingFactory.php on line 34 #0 /home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Links.php(90): Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory->create(Object(Drupal\drupalmoduleupgrader\Routing\Drupal7\RouteWrapper), NULL)
#1 /home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/drupalmoduleupgrader.drush.inc(352): Drupal\drupalmoduleupgrader\Plugin\DMU\Converter\Links->convert(Object(Drupal\drupalmoduleupgrader\Target))
#2 phar:///usr/local/bin/drush/includes/command.inc(422): drush_drupalmoduleupgrader_dmu_upgrade('registration_ty...')
#3 phar:///usr/local/bin/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#4 phar:///usr/local/bin/drush/includes/command.inc(199): drush_command('registration_ty...')
#5 phar:///usr/local/bin/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#6 phar:///usr/local/bin/drush/includes/preflight.inc(67): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#7 phar:///usr/local/bin/drush/includes/startup.inc(465): drush_main()
#8 phar:///usr/local/bin/drush/includes/startup.inc(369): drush_run_main(false, '/', 'Phar detected. ...')
#9 phar:///usr/local/bin/drush/drush(114): drush_startup(Array)
#10 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#11 {main}
TypeError: Argument 2 passed to Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory::create() must be an instance of Drupal\drupalmoduleupgrader\Routing\Drupal8\RouteWrapper, null given, called in /home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Plugin/DMU/Converter/Links.php on line 90 in Drupal\drupalmoduleupgrader\Routing\LinkBinding\LinkBindingFactory->create() (line 34 of /home/foobar/public_html/ea.foobar.com/web/modules/contrib/drupalmoduleupgrader/src/Routing/LinkBinding/LinkBindingFactory.php).
Drush command terminated abnormally due to an unrecoverable error.   [error]

earthangelconsulting → created an issue.

yes please, maintainers! let us know if this is actually going to make it to Drupal 9 / 10 or if it has been abandoned, or... what?

it seems that i COULD download (or install via Composer, if it permits it) this release https://www.drupal.org/project/simple_access/releases/8.x-3.0-alpha7 → (committed 25 Sept, 2021, according to #20 ) and... then what? do i still need to apply this patch https://www.drupal.org/files/issues/2021-06-19/drupal-9-readiness-314550... → (#19) or has that now been merged in? i am guessing the latter. but does it work?

the elephant in the room: if this module is even remotely capable of working under D9, why is there no D8 or D9 versions shown on the main module page? (i only found the 8.x-2.0-alpha7 module in the https://www.drupal.org/project/simple_access/releases → page )

if this porting to D9/10 is totally abandoned, it would be great if the maintainers could just tell us so! :-)

Also, since they understand the original intent behind the module, and what other options there are for access control... what would be the recommended way of accomplishing the same in D9? i am new to D9 but i don't think this is in Core. what module should be used instead?