Hi...
Just adding it here in case it helps...
I use a different module (redirect) but was having exactly the same issue with an addtitional detail... the redirect would work only if I added a trailing slash...
So...
When I archived the page https://mysite.com/mypage and created a redirect to https://mysite.com/newpage , the redirect would only work if I added the trailing slash, i.e., if I tried to reach https://mysite.com/mypage/ . If I didn't have the trailing slash, I would get the same "Access Denied" error described in this article.
I solved this by changing the alias of the archived page to something else like "mypage-legacy" (AFTER archiving it and AFTER adding the redirect). As "mypage-legacy" was never live it didn't need redirect. And now, the original page URL ("https://mysite.com/mypage") redirects to "newpage" with or without a trailing slash.
Problem solved... good luck...
Hi,
I had a similar issue to nagender16 (#9)
When I applied the patch, I was not able to edit any entity of a content type that has a workflow associated to it.
The full error message I get is as follows:
The website encountered an unexpected error. Try again later.
InvalidArgumentException: The state '' does not exist in workflow. in Drupal\workflows\Plugin\WorkflowTypeBase->getState() (line 155 of core/modules/workflows/src/Plugin/WorkflowTypeBase.php).
Drupal\content_moderation\Plugin\WorkflowType\ContentModeration->getState(NULL) (Line: 366)
Drupal\content_moderation\EntityTypeInfo->formAlter(Array, Object, 'node_program_intake_edit_form') (Line: 165)
content_moderation_form_alter(Array, Object, 'node_program_intake_edit_form') (Line: 545)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'node_program_intake_edit_form') (Line: 841)
Drupal\Core\Form\FormBuilder->prepareForm('node_program_intake_edit_form', Array, Object) (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 270)
Drupal\shield\ShieldMiddleware->bypass(Object, 1, 1) (Line: 137)
Drupal\shield\ShieldMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
So, for the sake of trying something different, I made the patch local and tried to define $value as public and private.
When made public, I got this error:
Fatal error: Access level to Drupal\Core\TypedData\PrimitiveBase::$value must be public (as in class Drupal\Core\TypedData\TypedData) in /var/www/docroot/core/lib/Drupal/Core/TypedData/PrimitiveBase.php on line 8
When made it private I didn't get an error...
aarantes → created an issue.
Yes, my problem disappeared when I installed DER 3.2.0
Thanks.
Got virtually the same issue when upgrading to Drupal 10.2.2
Using DER 3.1.0
In my case, I get this during the upgrade itself (composer) but also running (drush updb, drush cex, and drush cr)
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779
[warning] Undefined array key "target_type" EntityReferenceItem.php:778
[warning] Undefined array key "handler_settings" EntityReferenceItem.php:779I was able to upgrade from 9.5.10 to 10.1.1, in case someone else hits the wall like I did:
-
First, ensure that your underlying tools are up to date and are compatible with Drupal 10. I'm talking about PHP, Drush, BLT, node, etc (whatever you use)
-
Identified two groups of modules: modules that have versions which were only compatible with either Drupal 9 or Drupal 10 (ex: dynamic entity reference); modules for which there are patches for Drupal 10 but are not "officially" compatible with Drupal 10, i.e., in packagist.org they are still shown as being compatible only with Drupal 9. Aparently Composer uses packagist.org as the basis to define if a module is or is not compabiel with drupal 10 (NOT a patched info.yml file).
-
From the groups above, remove all of those for which it makes more sense to remove them now and reinstall them later, than to try and upgrade them. For example, a module with simple or no configuration, and no impact on other modules, might be easer to remove and reinstall later. One example for me was OnPointSearch.
-
For the modules that I decided not to remove, I've installed and configured mglaman/composer-drupal-lenient and configured it for all of them. After installing this module, here is an example of a composer command to add a new module to the list of lenient modules:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/dynamic_entity_reference"]'
-
In my case I also had to remove the following modules: behat/behat, behat/mink-extension, and drupal/drupal-extension (I've reinstalled them after upgrade).
-
I have 5 projects and for some of them, after failing repeatedly on the core upgrade itself, I just "gave up" and ran a
composer requirecommand with the flag "-W" for each contributed module (I'm pretty sure the previous administrator didn't use that flag so a few of them had updates available for their dependencies). Yet, I can't be sure which ones (if any) were holding me back. -
Nevertheless, at this point I was able to finally upgrade to D10
-
Update all modules you included in your "lenient" list
-
Reinstall and configure all modules you removed
If you are using composer (which I'm assuming you are), don't forget to update the database and export the configuration so you can deploy to production.
One last bit of advise: don't forget to inspect your pages on a browser to be sure that not only your custom code but also contributed modules have moved away from the jQuery "Once" library in favor of the Drupal library of the same name (the JavaScript code has to be updated accordingly.) I remember having to install a patch to a contributed module because their code was still relying on jQuery's Once library.
Hope it helps others. Good luck!
I had the same issue when updating from 1.0.0-beta1 to 2.0.0-alpha5.
After update (successful), ran "drush updb" and got these messages:
> [notice] Update started: rabbit_hole_update_8103
> [notice] Update completed: rabbit_hole_update_8103
> [notice] Update started: rabbit_hole_update_8104
> [notice] Update completed: rabbit_hole_update_8104
> [notice] Update started: rabbit_hole_update_8105
> [notice] Update completed: rabbit_hole_update_8105
> [notice] Update started: rabbit_hole_update_8106
> [error] 'rh_action' not found
> [error] Update failed: rabbit_hole_update_8106
[error] Update aborted by: rabbit_hole_update_8106
[error] Finished performing updates.
No problem exporting (drush cex).
As of now, no visible issues on the site.
Thank you @TolstoyDotCom,
Unfortunately DER is quite extensively used on all sites. Each site has at least 10 different content types (one of them has close to 40) and in each one of those, DER has been used multiple times.
I'm fairly new to Drupal (I inherited these sites about a year ago, so I don't have as much experience), but doesn't Drupal have a "best practices" for situations like this?
Moreover, the truth is that I don't even know if this is the reason why the upgrade itself is failing as the messages actually only talk about drupal core itself.
The response to the composer prohibits command is flawed, as I installed patches for node_title_help_text and onpoint_search module and they both show as compliant with Drupal 10 when I run the "upgrade status" module.
Thanks again,
Alex
Workaround in #5 just worked for me too on 9.5.9.
aarantes → created an issue.
On my site, I have a default theme "A" and administration theme "B".
In "Theme Switcher", I'm changing the administration theme to theme "A". To apply this change, I'm using two conditions: "Request Path" and "User Role".
On my production site (still running 8.x-1.2 with Drupal 9.5.8), it works as expected, i.e., only those of a certain "User Role" (I selected 4 roles), AND reaching a specific path (I defined one "Request Path"), are served with the page using theme "A". All other roles use the standard theme "B" in all paths (including the one I defined in "Request Path") as well as those from the 4 roles I defined, when going to ANY path other than the one in "Request Path".
On my dev environment (running 2.0 with Drupal 9.5.9) the conditions seem to change from AND to OR . ALL roles get theme "A" when going to the path defined in "Request Path". And those people in one of those four roles defined in "User Role" get theme "A" everywhere.