Again, the problem should be solved rather than completely removing all functionality. Therefore, unfortunately, I am absolutely against 📌 [Opinions welcome] Remove customizable options Needs review being implemented in this form.
I have only just seen this issue and would like to write a few lines about it. I would actually extend the options instead of removing them completely.
At the moment I use a customised login and registration information page after the user has logged in or registered. It is part of good UX that the user is always informed about what has happened and receives further information.
I would even go so far as to implement templates and custom fields for all three points mentioned. In the configuration, you could then offer an image field, title and text, for example. This would tell the user what has happened and what to do next.
In my project, the link "What? No password?" is called up very often because many people don't understand how a registration or login is supposed to work without a password. Everything is explained there.
That's why I'm actually against the removal, but for a technical implementation for the three things: Configuration fields and templates, the module is supposed to help users and if the options are removed, it won't help at all. We would like to see a concept in which this becomes a standard and thus further promotes security.
PS: the current version of the module 2.0.0-beta2, has changed so much that you can't update it. the whole custom logic for help pages after login/registration is no longer supported, which is unfortunately not the right way for this module in my opinion.
A version for Group 2.x was already prepared, but could not be released because it is untested. I have published a new release for Group 2.x, you are welcome to test it and if something does not fit, then make adjustments directly for the version.
https://www.drupal.org/project/group_storage/releases/2.0.0-beta1 →
+1 RTBC
@Wim Leers Thanks again for your support. It was a very wild ride for me, but everything is finally working as it should. Unfortunately I can't explain why it was such a problem with this module in particular. What I did: deactivated and uninstalled the module, deployed to prod, downgraded the module, deployed to prod, deactivated and uninstalled the module, deployed to prod, installed the current version, deployed to prod... everything was fine. really, i have absolutely no idea why this was such a struggle.
but you are absolutely right, tests are successful, current version runs as it should and i now have the current code version on the productive environment with MAIN, instead of MASTER.
Thanks again and sorry for the struggle :)
I have the current stable version: 2.2.0. The line 138 on the productive environment looks like this, see screenshot. But I also see that it is correct in the source code of the module: https://git.drupalcode.org/project/big_pipe_sessionless/-/blob/2.x/src/R...
I'm trying to completely uninstall the module, remove it, with between deployments and reinstall it so that the correct code is used. However, I really can't explain why this is the case :(
I can confirm, with Drupal 10.2.1 everything works perfectly without patch :)
Yesterday I updated the entire productive stack, including Drupal to version 10.2.1. I tried again to activate the sessionless BigPipe, as soon as this happens, pretty much all calls on the productive environment break.
Unfortunately, the error remains, and I cannot reproduce the error locally either.
A spontaneous idea, I still have the Quicklink module in use, could it be that both modules are interfering with each other? Both modules used to run without problems, but a lot has changed with Drupal and the modules. Perhaps the combination of the two does not fit here. At least that's my only assumption at the moment.
Full error stack:
Error: Call to undefined method Symfony\Component\HttpFoundation\RequestStack::getMasterRequest() in Drupal\big_pipe_sessionless\Render\BigPipeSessionless->primePageCache() (Zeile 138 in /var/www/vhosts/docroot/modules/contrib/big_pipe_sessionless/src/Render/BigPipeSessionless.php)
#0 /var/www/vhosts/docroot/modules/contrib/big_pipe_sessionless/src/Render/BigPipeSessionless.php(85): Drupal\big_pipe_sessionless\Render\BigPipeSessionless->primePageCache()
#1 /var/www/vhosts/docroot/core/modules/big_pipe/src/Render/BigPipeResponse.php(112): Drupal\big_pipe_sessionless\Render\BigPipeSessionless->sendContent()
#2 /var/www/vhosts/vendor/symfony/http-foundation/Response.php(425): Drupal\big_pipe\Render\BigPipeResponse->sendContent()
#3 /var/www/vhosts/docroot/index.php(20): Symfony\Component\HttpFoundation\Response->send()
#4 {main}Patch in comment #27 works great, from my side RTBC+
@sd123: I was able to solve the problem with the error, here in the issue 💬 Aggregation not working css and js cache directories not being created Postponed: needs info , comment #42. after that I can deactivate and activate the module. but as soon as I activate the module, I have the problem with ERR_QUIC_PROTOCOL_ERROR.
i will test the patch from comment 27 soon and hope it helps, thanks for the work @sense-design
@yan Thanks, had the exact same problem after updating to Drupal 10.2... your solution worked great.
@slydevil actually, the problem has nothing to do with minifyhtml or minifyjs. if both modules are uninstalled on the stage, the form simply cannot be saved. it's just an idea that it might also be related to this problem after the update to drupal 10.2. with drupal 10.1 I had absolutely no problems, so something must have been changed in drupal 10.2 that you now have this problem.
i also found this issue, which doesn't quite fit the topic, but sounds similar only with a different outcome: 📌 Remove the aggregate stale file threshold and state entry Fixed .
I have the same problem, I use Config Split for the stage and production environments. Locally the minifiyng is deactivated. Just rolled out a current version with Drupal 10.2, PHP 8.1.26, HTTP/2 nginx 1.24.0 on the stage. After the deployment I always do standardised tests, I noticed that neither *.js nor html were minified. under en/admin/config/development/performance I saw that the checkboxes for Minified Source HTML. and Minified JavaScript files. were not activated (although set in the configuration). When trying to activate them, the following error message appears, the form cannot be saved: 'stale_file_threshold' is not a supported key.
In the dblog I find the following on the stage, but everything was fine locally:
Deprecated function: preg_quote(): Passing null to parameter #1 ($str) of type string is deprecated in Drupal\Core\Path\PathMatcher->matchPath() (line 82 of /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Path/PathMatcher.php)
#0 /var/www/vhosts/site/stage/docroot/core/includes/bootstrap.inc(164): _drupal_error_handler_real()
#1 [internal function]: _drupal_error_handler()
#2 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Path/PathMatcher.php(82): preg_quote()
#3 /var/www/vhosts/site/stage/docroot/modules/contrib/minifyjs/src/MinifyJs.php(296): Drupal\Core\Path\PathMatcher->matchPath()
#4 /var/www/vhosts/site/stage/docroot/modules/contrib/minifyjs/minifyjs.module(21): Drupal\minifyjs\MinifyJs->loadAllFiles()
#5 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(545): minifyjs_form_system_performance_settings_alter()
#6 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(841): Drupal\Core\Extension\ModuleHandler->alter()
#7 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(284): Drupal\Core\Form\FormBuilder->prepareForm()
#8 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(224): Drupal\Core\Form\FormBuilder->buildForm()
#9 /var/www/vhosts/site/stage/docroot/core/modules/system/src/Controller/PerformanceController.php(24): Drupal\Core\Form\FormBuilder->getForm()
#10 [internal function]: Drupal\system\Controller\PerformanceController->build()
#11 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#12 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#13 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext()
#14 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#15 /var/www/vhosts/site/stage/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#16 /var/www/vhosts/site/stage/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#17 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle()
#18 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#19 /var/www/vhosts/site/stage/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#20 /var/www/vhosts/site/stage/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#21 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#22 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#23 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#24 /var/www/vhosts/site/stage/docroot/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#25 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle()
#26 /var/www/vhosts/site/stage/docroot/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#27 /var/www/vhosts/site/stage/docroot/index.php(19): Drupal\Core\DrupalKernel->handle()
#28 {main}This is not yet correct and functional in this form, the patch needs to be revised/extended.
The feature is really great, at this point a note that the patch is not compatible with Drupal 10.2. see details here in the issue: 🐛 system.performance.yml no longer considered after update Closed: works as designed
Thanks again for the shared consideration, found the problem, it was due to this patch
✨
Allow to validate Apache/Nginx configuration requirement for aggregation folder before enabling aggregation.
Needs review
. Once the patch is removed, the system.performance.yml remains and everything works normally.
thanks for the idea, yes two settings are set for the local environment, see here:
// Disable CSS and JS aggregation.
$config['system.performance']['js']['preprocess'] = FALSE;
$config['system.performance']['css']['preprocess'] = FALSE;
but even when removing these, the problem unfortunately remains. after updating to drupal 10.2, running drush updb and drush cex, the system.performance.yml file is simply deleted and therefore no form exists, which of course cannot be generated in the ui.
even if the file is then restored manually and the configuration is imported via drush cim, this is completely ignored.
zcht → created an issue.
Yes, this also happens if config split is completely deactivated/uninstalled. An empty system.performance.yml file is simply created. If you take the values from a default file and try to import the configuration, the file is simply ignored. if you call up /development/performance since, you get the same error.
in my configuration with config split, the file is only changed for the stage and production environment. otherwise the configuration file for the locale environment can be managed normally with drupal, not with config split
the only thing i did: updated drupal from 10.1.6 to 10.2.0 via composer, ran drush updb -y and drush cex -y. the mentioned file is recreated, the only content in the file is { }
back to drupal 10.1.6 everything works normally again, the ui can be called up, the file has configuration. i'm trying to get to the bottom of the problem here, but so far i don't see a solution.
Thanks for the patch, ran into the same problem as @Anybody listed. In my case though only in a media field (not private) provided in a paragraph, was only discovered by accident because this field is rarely used. The patch fixes the problem, successfully tested on Drupal 10.1.6
RTBC++
thanks for the test, here is the updated version.
I have created a small patch here that fixes the problems mentioned above. If necessary, this must/might be extended so that we really ship a "professional" robots.txt as standard with Drupal 10.x
Thanks for your feedback, unfortunately I don't understand that either. Thanks for the tip for the symfony version, the composer.lock has the following stored in it:
"symfony/console":"^6.3",
"symfony/dependency-injection":"^6.3",
"symfony/event-dispatcher":"^6.3",
"symfony/http-foundation":"^6.3",
"symfony/http-kernel":"^6.3",
"symfony/mime":"^6.3",
"symfony/polyfill-iconv":"^1.26",
"symfony/process":"^6.3",
"symfony/psr-http-message-bridge":"^2.1",
"symfony/routing":"^6.3",
"symfony/serializer":"^6.3",
"symfony/validator":"^6.3",
"symfony/yaml":"^6.3",When checked on the server itself, all the necessary libraries are included. It can't be Symfony per se, otherwise I wouldn't be able to install Drupal 10.1.x and use various modules and services. It must be something else, but unfortunately I can't explain it at the moment either.
Just tested again, after I have executed a complete new build via Gitlab CI on the productive environment, I have explicitly set the Sessionless BigPipe module to version 2.2.0. Unfortunately, the same error remains, dblog log contains the errors listed above, the website becomes extremely slow... as soon as the module is deactivated, everything is normal and fast again.
I wrote in my first issue: Drupal 10.1.5, PHP 8.1.24, nginx 1.24
yes, i also saw that the tests ran successfully. unfortunately, the error does occur on the productive environment.
zcht → created an issue.
Thanks for the update: yes, looks good now, no errors, the results on production with Search API 4.2.x resemble the Search API 4.3.x with the patch. Everything seems to work fine.
So from my side gladly a RTBC++
Thanks for the analysis and the patch, which unfortunately does not quite work for me yet. My setup looks like this: Drupal 10.1.4, Search API 4.3.x, PHP 8.1.x, nginx. The patch is applied cleanly, however after reindexing the index, the search results (filtered by relevance) are not output, which are configured with Search Overrides.
In detail, when viewing and e.g. a cache clear via drush cr, the following error message comes up, this actually only occurs when the patch is applied. Without the patch, everything works normally, except for the search overrides of course. It is true that I did not test it with a fresh installation, but directly in my project to have some database and simulate the productive environment.
In CheckDefinitionValidityPass.php line 61:
The definition for "tags" has no class. If you intend to inject this service dynamically at runtime, please mark it as synthetic=true. If this is an abstract definition solely used by child definitions, please add abstract=true, otherwise specify a class to get rid of this error.Symfony\Component\DependencyInjection\Exception\RuntimeException: The definition for "tags" has no class. If you intend to inject this service dynamically at runtime, please mark it as synthetic=true. If this is an abstract definition solely used by child definitions, please add abstract=true, otherwise specify a class to get rid of this error. in Symfony\Component\DependencyInjection\Compiler\CheckDefinitionValidityPass->process() (line 61 of /var/www/html/vendor/symfony/dependency-injection/Compiler/CheckDefinitionValidityPass.php).
Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object) (Line: 767)
Symfony\Component\DependencyInjection\ContainerBuilder->compile() (Line: 1335)
Drupal\Core\DrupalKernel->compileContainer() (Line: 934)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 1186)
Drupal\Core\DrupalKernel->rebuildContainer() (Line: 503)
drupal_flush_all_caches() (Line: 205)
Drupal\admin_toolbar_tools\Controller\ToolbarController->flushAll()
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 182)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->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: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)@mkalkbrenner thanks for your analysis and feedback in the other issue. then i didn't say anything here in this issue :)
Unfortunately I have the same problem, described here 🐛 Undefined method RequestStack::getMasterRequest() Closed: duplicate , the patch from this issue does not help.
My mistake, I overlooked the existing issue: 🐛 Call to undefined method RequestStack::getMainRequest() Postponed: needs info
Although it is mentioned in another issue ( 💬 Type boosting no longer works well with Search API 4.3.x Active ), for another module as well. But boosting (by relevance of course) unfortunately doesn't work since 4.3.x, but with 4.2.x, drupal 10.1.x and Sorl 8.11.2 everything works fine.
I have re-exported the configuration, actually also adjusted the processors, done everything as it should. but the boosting, according to certain schema, unfortunately does not work.
I think that something was adjusted here and it now works differently. I am still testing to find out what exactly, unfortunately without success so far.
The patch #2 also works excellently under Group 1.6.
@masoom2206 What makes you think it doesn't work? Your patch is, by the way, a 1:1 copy, no difference to patch #2.
@Ambient.Impact Very good attention, thank you for reporting the bug and the so intensive and detailed analysis. You're absolutely right, unfortunately I didn't think about the fact that the field can remain empty during the implementation and didn't test this implementation. Of course that makes sense then that the function doesn't work as it should.
Thanks also for the unit tests, really 1A work. The tests are implemented for the project and a new bugfix release is coming soon.
zcht → made their first commit to this issue’s fork.
Have now actually needed it urgently, and already built its own patch... well watched @hernani, thank you
@kristiaanvandeneynde After the successful release of 'Initiative for Group 1.x compatibility under Drupal 10', could you take a look at this plan before a new release is put out? Thanks.
In my case with 10.1.1, at the moment running on the productive environment Drupal 9.5.10, in the meantime, the instance was prepared for Drupal 10 and updated to the then most current Drupal 10.0.x. Under this version everything still ran problem-free, after the update to 10.1.1 and now 10.1.2, came the problem, which could not be solved so far. All under the same PHP and nginx version.
I have exactly the same problem unfortunately, aggregation turned off, everything works, turned on.... 404 error and the files are not generated. I use Drupal 10.1.2, PHP 8.1.22, nginx 1.24. The new nginx statement from the CR ( https://www.drupal.org/node/2888767 → ) are implemented. Also the tips from the issues from comment 2 have already been worked through, nothing helps unfortunately.
Two new user agents, one from China and the other from the USA. Sometimes cause problems with login, the email links are scanned in advance and invalidated. You could check this and if it is the case, add it to the configuration to block it. It has not yet been possible to find out which companies the user agents belong to.
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/83.0.4103.97 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/75.0.3770.142 Safari/537.36Thanks for pointing that out, the patch unfortunately didn't solve all the spots cleanly, so a little reroll.
A small update, the " Shy One Time → " module has been updated to version 2.x. Via the Drupal state API you can now block unwanted user agents that access the route 'user.reset'. The users I mentioned in comment 40 can now log in without problems.
CrawlerDetect as a large library already works very well. After internal testing it was found that not all crawlers/bots are covered. Especially users working with Microsoft Office 365 and therefore Outlook noticed very often that login is not possible. Upon closer analysis, it was found that the MS/Bing crawlers are particularly persistent and repeatedly call the reset links, regardless of server configuration or the like. For this reason, a text field was implemented in the backend via the Drupal State API, in which selected user agents (always one per line) can be entered. These are checked by 'Shy One Time', in case of a hit a redirect to the LogIn form with a 302 status code occurs, the reset link is not invalidated.
Furthermore, logging has been implemented in dblog, which logs ALL user agents coming via the route 'user.reset'. So it can be tracked exactly which crawler is causing problems and this can be taken over into the custom user agent configuration. This way the evaluation of the server logs is not necessary, but can be used additionally for verification.
The additional support for the 'passwordless' module has been removed. From now on a generic solution is followed via the internal route 'user.reset', so supports all modules that access this route.
---
After installing the module in version 2.x, the configuration interface can be reached via the link /admin/config/system/shy_one_time. User agents that are unwanted and should be blocked are entered in the text field. Only ONE user agent may be inserted per line. For more information, see the README.md.
---
The problem arose with the 'Agreement' module in version 3.0.0-alpha2 (an issue will follow in the project), the error message was the following:
Warning: Undefined array key "" in /var/www/html/docroot/core/modules/views_ui/src/ViewFormBase.php on line 162
Warning: Trying to access array offset on value of type null in /var/www/html/docroot/core/modules/views_ui/src/ViewFormBase.php on line 162
Deprecated: mb_strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/docroot/core/modules/views_ui/views_ui.module on line 347
The website encountered an unexpected error. Please try again later.
Error: Call to a member function isEnabled() on null in Drupal\views_ui\ViewEditForm->getDisplayDetails() (line 421 of core/modules/views_ui/src/ViewEditForm.php).
Drupal\views_ui\ViewEditForm->getDisplayTab(Object) (Line: 212)
Drupal\views_ui\ViewEditForm->form(Array, Object) (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object) (Line: 41)
Drupal\views_ui\ViewFormBase->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('view_edit_form', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'edit', Array) (Line: 230)
Drupal\views_ui\Controller\ViewsUIController->edit(Object, NULL)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 583)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->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: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
So I started to look in detail what the problem is, just discovered that the function views_ui_truncate() as described by me is not error free under PHP 8.1.
The problem with the contrib module Agreement has indirectly to do with the function I mentioned. However, I find that
- a) the function
views_ui_truncate()should be made more error-tolerant, although most of the problems will probably have to do with contrib. - b) Compatibility for PHP 8.1 must be made anyway.
reroll patch, small error with the separator and thus duplicated string.
Here would be my suggestion as a patch, recommendations and further evaluations are welcome.
Hi @MacSim, thanks for the great update. I was able to test the new 2.x dev version for a few days and it looks really great.
From my side gladly RTBC++ :)
This problem is fixed within the scope of this issue 📌 Initiative for Group 1.x compatibility under Drupal 10 Fixed , so it is a duplicate.
This problem is fixed within the scope of this issue 📌 Initiative for Group 1.x compatibility under Drupal 10 Fixed , so it is a duplicate.
Also here, found some more. Existing accessCheck should NOT be changed, patch reroled.
@kristiaanvandeneynde yes, you are absolutely right. existing accessCheck must not be changed of course, I did not pay attention to it. patch is reworked:
- - existing accessChecks are the same
- - in case of not existing accessCheck they are inserted with TRUE
- - ProphecyTrait removed, was an "optimization" of phpStorm
patch reroll with the adjustments from the patch from comment #8
This patch should fix the problem: #3357151 🐛 Use core/internal.backbone lib Needs work
Thanks for the patch, in my case on Drupal 10.1 SHS & Chosen (dev-2.0.x 702b07e) did not work as a widget, via 31 javascript error, it just output a text input field with the ID of a term. This patch has fixed the problem, so also here RTBC +1 and please be sure to apply in the module core.
and here is the small patch.
Thanks for the review, here is the update of the patch.
With all execute an access check was missing. Here is a patch, tested under Drupal 9.5.9 & 10.0.9, PHP 8.1.x.
I have created a first version of a possible patch. I'm not the right person for UNIT tests, maybe someone else could do that, but the first tests are very promising: tested in a custom project of my own with over 4,000 groups & subgroups, Drupal 10.0.9, PHP 8.1.17, only minor adjustments to custom modules of my own were necessary, but related to Drupal 10. So far everything works well and error free, testing will continue and testing is welcome.
Patch rerolled, on closer testing it was noticed that in the subgroup.module the statement for $event_dispatcher was in the wrong order and led to a fatal error under Drupal 10 when creating or updating a subgroup.
Patch is no longer compatible with Drupal 10, a compatible version was created on the first base of the patch.
Small update from my side: we currently have a problem that some users who use Microsoft Office 365 do not receive emails. Even with our additional module, which works well, this is not remedied. It seems that MS Office 365 has introduced new crawlers or ways of accessing the link.
However, it does not affect all MS Office 365 users, at the moment only 4... nevertheless, of course, it's obvious that these users can't log in.
In my eyes it is also a problem of Drupal.... you cant tell the email providers how to define their own services to access a, in comparison, small Drupal site, which you have released yourself. I am absolutely with @gagarine, and a feature request is definitely NOT.
perspective, i think something should be done actively on the Drupal side. more and more services crawl all links, whether it's microsoft, slack or other services. That's the future right now and if we don't change something, you're going to exclude users from Drupal who can't log in.
Unfortunately, the patch with the adjustments for coding standards collides with the important patch # 3281672 🐛 doAddLeaf & doRemoveLeaf: timestamp bug and scalability Fixed
The patch of @Jan-E I see as mandatory for the next release of Subgroup. So here is the minimum version for compatibility for Drupal 10.
Have now created the first patch that works for me. No errors are thrown, subgroups can be edited and created. Fixed minor coding standards, set minimum group version to 1.5, declared Drupal 9.5 as minimum version. Tested under PHP 8.1, Drupal 9.5.9 & Drupal 10.x
Feedback and testing would be appreciated.
The MR for compatibility already goes in the right direction, however, this is buggy, at the moment in no case use in productive environment. The patch itself applied clean and everything works as it should, existing subgroups can be edited/updated/displayed. BUT: as soon as a new subgroup is created an extremely ugly error occurs. Subgroups are created, but not linked to the group, here the logic is completely broken. Thus linked node types cannot be inserted into the subgroup or other entities.
On closer analysis I found that after the patch no relationships are created for subgroup_depth, subgroup_left, subgroup_right, subgroup_tree. The logic for this seems to be completely missing. On further analysis and testing, I also get error messages when new entities are added to the subgroup.
My setup consists of Drupal 9.5.9, PHP 8.1, Group 1.5 and Subgroup 1.0.2
The website encountered an unexpected error. Please try again later.
Error: Undefined constant "Drupal\subgroup\Event\Symfony\Contracts\EventDispatcher\Event" in include() (line 6 of modules/contrib/subgroup/src/Event/GroupLeafEvent.php).
include() (Line: 582)
Composer\Autoload\{closure}('/var/www/html/docroot/modules/contrib/subgroup/src/Event/GroupLeafEvent.php') (Line: 433)
Composer\Autoload\ClassLoader->loadClass('Drupal\subgroup\Event\GroupLeafEvent') (Line: 91)
subgroup_group_update(Object)
call_user_func_array(Object, Array) (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'subgroup') (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('group_update', Object) (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll('group_update', Array) (Line: 249)
Drupal\Core\Entity\EntityStorageBase->invokeHook('update', Object) (Line: 900)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('update', Object) (Line: 598)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, 1) (Line: 781)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, 1) (Line: 523)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 804)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 339)
Drupal\Core\Entity\EntityBase->save() (Line: 51)
Drupal\subgroup\Entity\GroupSubgroupHandler->writeLeafData(Object, 1, 2, 3, 8610) (Line: 278)
Drupal\subgroup\Entity\SubgroupHandlerBase->doAddLeaf(Object, Object) (Line: 103)
Drupal\subgroup\Entity\GroupSubgroupHandler->doAddLeaf(Object, Object) (Line: 213)
Drupal\subgroup\Entity\SubgroupHandlerBase->addLeaf(Object, Object) (Line: 240)
subgroup_group_content_insert(Object)
call_user_func_array(Object, Array) (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'subgroup') (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('group_content_insert', Object) (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll('group_content_insert', Array) (Line: 249)
Drupal\Core\Entity\EntityStorageBase->invokeHook('insert', Object) (Line: 900)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('insert', Object) (Line: 598)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, ) (Line: 781)
Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, ) (Line: 523)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 804)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 157)
Drupal\group\Entity\Group->addContent(Object, 'subgroup:MYSUBGROUPNAME', Array) (Line: 656)
group_content_entity_submit(Array, Object)
call_user_func_array('group_content_entity_submit', Array) (Line: 114)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('group_MYSUBGROUPNAME_add_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'add', Array) (Line: 368)
Drupal\group\Entity\Controller\GroupContentController->createForm(Object, 'subgroup:MYSUBGROUPNAME')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
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: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->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: 49)
Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)no problem and gladly, thank you for the work and support of the project. :)
Thanks @philipnorton42, yes find the approach also good and more generic it is too. I'm so happy to take over the patch and make a new release right away. Thanks for the work.