🇱🇹Lithuania @vibrasphere

I don't think it's the CSS/JS file amount, because I still get same with aggregation on with all files compressed into one.

Also I don't think 'Load AOS library' option work under admin/config/user-interface/aosjs/settings ON or OFF it always loads the aos.js that comes with the module no matter what.

With all selectors disabled and the setting to load library turned off it still loads the aosjs/lib/v2/aos.js and aos.css

That's the point, I did all that, no errors and best part I get same/similar issue with other AOS modules, e.g. https://www.drupal.org/project/animate_on_scroll →

I'm losing my mind here.

I might record some video.

vibrasphere → created an issue.

The module doesn't work with main navigation that ships with Drupal installation and using the bootstrap5 sub-theme, but it does work with custom created menus. Link classes apply for my custom menus, but not for main navigation.

Working alternative https://www.drupal.org/project/link_attributes →

Also the parent ul class gets renamed from .nav to .menu with menus_attribute, but stays .nav with link_attributes (all tested on bootstrap5 sub-theme)

There you go 💰💰💰

Same with latest dev version.

Select Google Nexus or Mean Menu and you get Oops, something went wrong. Check your browser's developer console for more details.

Console:

XHRPOST
http://127.0.0.1/htdocs/admin/config/user-interface/responsive_menus?ajax_form=1&_wrapper_format=drupal_ajax
[HTTP/1.1 500 500 Service unavailable (with message) 181ms]

Uncaught 
Object { message: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 500\nDebugging information follows.\nPath: /htdocs/admin/config/user-interface/responsive_menus?ajax_form=1\nStatusText: 500 Service unavailable (with message)\nResponseText: The website encountered an unexpected error. Try again later.", name: "AjaxError", stack: "@http://127.0.0.1/htdocs/core/misc/ajax.js?v=10.2.5:196:32\n@http://127.0.0.1/htdocs/core/misc/ajax.js?v=10.2.5:1916:3\n" }
ajax.js:196:32

Click save and fatal crash.

​

vibrasphere → created an issue.

RIP

By ckeditor_font do you mean https://www.drupal.org/project/ckeditor_font → ? Because that is CK4 only, not 5.

#10 works, but expected old classic formatting, icons, numbers, etc.

Expected:

Not:

vibrasphere → created an issue.

Yes your scenario works too. But only on fresh D7 install. I can't do it on production.

Yes, the current workaround is to remove the Access rule for Total Control to be able to install and use User Revision together with Total Control with no errors.

If you install User Revision first there are no errors, but really can't do that on existing production website, where Total Control already fully set up and running.

Just saying, there's weird conflict between these two modules, because none of the errors are reported when enabling any other module, only with User Revision.

Duplicate

Solution https://www.drupal.org/project/total_control/issues/2225683 →

The possible root cause:

If you go and edit the Total Control administrative dashboard under Access tab at admin/structure/pages/nojs/operation/page-dashboard/settings/access and simply delete the Logged in user has "Have total control" and enable the User Revision, there are no errors.

I tested it by readding that Access rule and enabling User Revision and all the errors re-appear.

So I guess this is it. But I still do not understand how or why these two are related.

Current temporary fix is to either delete that Access rule for Total Control or completely disable/uninstall Total Control module, just to install User Revision without any errors.

Okay I drilled it down further:

1. Go to admin/structure/pages
2. Disable Total Control administrative dashboard
3. Enable User revision: no errors
4. Disable and uninstall User revision
5. Enable back Total Control administrative dashboard
6. Enable User Revision: all the errors appear.

Okay I think I was able to reproduce it, not sure why or how it's related to User Revision, but there it is:

Reproduce:
1. Install fresh Drupal 7
2. Enable CTools
3. Enable Total Control → (stable 2.4)
4. Enable User Revision
5. Check dblog for errors

All the listed user and ctools errors above happen only when enabling User Revision with Total Control already enabled. When enabling any other module errors do not appear.

No idea how this is related, because Total Control is only a Dashboard module?

vibrasphere → created an issue.

The ctools error I get is same as here https://www.drupal.org/project/user_revision/issues/3416827 🐛 Notice: Undefined property: stdClass::$uid in user_access() Active except mine says line 65, but not sure if this is any related. My error triggers when enabling the User Revision and not when visiting as anonymous, so not sure if related.

Notice: Undefined property: stdClass::$uid in ctools_context_create_user() (line 65 of /sites/all/modules/ctools/plugins/contexts/user.inc).

Also when enabling User Revision there's a message at the top 537 records were added to {user_revision} table. Does that mean there's 537 users? There's one revision table created for each?

So far I'm trying to track down the errors by disabling modules one-by-one.

Tried enabling the module in another site and got fatal error/WSOD.

Disabled the module via drush and it got fixed.

Checked dblog:
Error: Attempt to assign property "logged_in_user" on bool in ctools_context_create_user() (line 46 of/sites/all/modules/ctools/plugins/contexts/user.inc).

I'm not sure.

addressfield
addressfield_phone
adminimal_admin_menu
admin_menu
admin_views
autologout
backup_migrate
better_exposed_filters
block_class
captcha
ckeditor
colorbox
commerce
commerce_extra_tokens
commerce_license
commerce_option
commerce_paypal
commerce_pricing_attributes
commerce_product_attributes
commerce_registration
commerce_rules_extra
conditional_fields
content_access
css_injector
ctools
custom
customer_profile_type_ui
date
email_registration
entity
entity_bundle_plugin
entityreference
extlink
feeds
feeds_xls
field_collection
field_group
field_permissions
filefield_paths
filefield_sources
filefield_sources_plupload
flexslider
fontawesome
fontyourface
globalredirect
iframe
imagecache_token
imagefield_tokens
imce
imce_copylink
imce_mkdir
job_scheduler
jquery_update
js_injector
judy
libraries
link
log_filter
mailsystem
menu_attributes
menu_editor
menu_per_role
menu_token
mimemail
nocurrent_pass
nodeaccess
opengraph_meta
panels
paranoia
path2ban
pathauto
pathologic
plupload
README.txt
realname
recaptcha
redirect
registration
registration_commerce
responsive_menus
rules
schema_metatag
security_review
select_or_other
shield
smart_ip_ban
special_menu_items
stringoverrides
superfish
tabtamer
token
token_filter
total_control
transliteration
userone
userprotect
user_revision
uuid
views
views_bulk_operations
views_data_export
views_export_xls
views_fieldsets
views_rules
webform
webform_validation
weight
xmlsitemap
youtube

vibrasphere → created an issue.

Happened same with Drupal 10.

Built the website on local Windows 10 and uploaded it to Ubuntu.

For some reason settings.php formatting was like this:

'autoload' => 'core/modules/mysql\\src\\Driver\\Database\\mysql\\',

And if you replace it with this, the issue is solved:
'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',

vibrasphere → created an issue.

Also applies on 7.x-2.0-rc10

vibrasphere → created an issue.

vibrasphere → created an issue.

But it's set to Optional and nothing indicates both fields must be filled.

Should be able to fill just one field.

vibrasphere → created an issue.

I'd like to confirm that patch #25 works perfectly with latest Drupal 10 verison using https://github.com/mglaman/composer-drupal-lenient

#29 works.

Patch works. Thanks.

This is an issue in D10.

1. E.g. the adminimal_theme/css/adminimal.css at line 759 looks for icons at given path e.g. /core/themes/stable/images/core/icons/787878/puzzlepiece.svg and it gives 404.
2. It's because there is no /stable/ because it has been removed https://www.drupal.org/node/3309392 →
3. The right path to the icon is e.g. /core/misc/icons/787878/puzzlepiece.svg

I mean on original post about live production site the issue still persists, but the client doesn't need it anymore. I just got solved this on my own personal sandbox.

Did another multiple resets in a row with https://www.drupal.org/project/drupal_reset → and now it's working? ¯\_(ツ)_/¯

1. Page not found only on superuser uid1, logged in as yourself with it, both View and Edit.
2. Creating any new random user works both View and Edit, creates revisions, etc.
3. Permissions default untouched all set to Administrator.
4. Installed stable latest version 2.1
5. PHP 7.4.22, 5.5.5-10.3.38-MariaDB-0ubuntu0.20.04.1, Linux dev 5.4.0-84-generic #94-Ubuntu

Hi, this patch solves the drush problem, but not visiting the user/1 Page not found issue.

I cannot understand how nobody is running into this problem, I'm doing this on fresh vanilla installation out of the box with no other modules, user_revision is first module installed.

How nobody else runs into this issue?

Can we have this committed please, still happening under stable 1.0.0.

This worked for 3.0.8 (but not for 3.0.7)

$ curl https://www.drupal.org/files/issues/2023-07-05/3366009-5.patch | git apply -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 63472  100 63472    0     0   308k      0 --:--:-- --:--:-- --:--:--  311k
Checking patch css/ck5style.css...
Checking patch css/style-52.css...
Checking patch css/style.css...
Checking patch scss/_variables_bootstrap.scss...
warning: scss/_variables_bootstrap.scss has type 100644, expected 100755
Applied patch css/ck5style.css cleanly.
Applied patch css/style-52.css cleanly.
Applied patch css/style.css cleanly.
Applied patch scss/_variables_bootstrap.scss cleanly.

It also changed input.form-search border color.

Yes, but the question is why it does not follow official colors?

We decided to move on, we get this error/issue on multiple sites prod and fresh. Thanks for all the help.

All commands gave me empty lines with no results, but it did fix drush? Drush now running fine with User Revision enabled.

But I still get Page not found when trying to open or edit any user profile.

Also drush ev "var_dump(drupal_get_installed_schema_version('user_version'))" now worked only once and gave int(-1), but doesn't work anymore and gives previous errors.

# drush cc all
'all' cache was cleared.                                                                                                                                        [success]
# drush updatedb
No database updates required                                                                                                                                    [success]
# drush sql-query "SELECT schema_version FROM system WHERE name = 'user_revision'"
7003

With User Revision module installed running drush ev "var_dump(drupal_get_installed_schema_version('user_version'))" gives same error as previous:

Could not login with user ID 0. This is typically caused by importing a MySQL database dump from a faulty tool which re-numbered the anonymous user ID in the   [error]
users table. See http://drupal.org/node/1029506 for help recovering from this situation.

With User Revision disabled it gives:

WD php: Error: Call to undefined function drupal_get_installed_schema_version() in eval() (line 1 of                                                            [error]
/var/www/example.com/composer/vendor/drush/drush/commands/core/core.drush.inc(1178) : eval()'d code).
Error: Call to undefined function drupal_get_installed_schema_version() in eval() (line 1 of /var/www/example.com/composer/vendor/drush/drush/commands/core/core.drush.inc(1178) : eval()'d code).
Drush command terminated abnormally due to an unrecoverable error.

This is on clean fresh install.

Drush version 8.4.12, PHP 7.4.

Hi, patch applies cleanly.

curl https://www.drupal.org/files/issues/2023-06-21/user_revision-breaks_drush-3367385-20.patch | git apply -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   891  100   891    0     0   4367      0 --:--:-- --:--:-- --:--:--  4367
Checking patch user_revision.install...
Applied patch user_revision.install cleanly.

1. Enable the module `drush en user_revision -y`
2. Run `drush updatedb` or/and update.php both yeld `No pending updates.`.

3. Run simple drush command e.g. `drush status`:

Could not login with user ID 0. This is typically caused by importing a MySQL database dump from a faulty tool which re-numbered the anonymous user ID in the   [error]
users table. See http://drupal.org/node/1029506 for help recovering from this situation.

4. Disable module User Revision, Drush problem solves and it works again.

I'm familiar with the basics.

Please attach the patch and I will try to apply it.

And thanks.

https://www.drupal.org/project/issues/user_revision?text=drush&status=All →

hmm interesting one from 12 years ago
https://www.drupal.org/project/user_revision/issues/1053398 →

My new priority would be to make it work with Drush first, because that's huge deal breaker. We run Drush on every website.

This is first time in 11+ years of Drupal and Drush I run into module that somehow breaks Drush.

I don't really work with databases so I'm not sure were we're even going with this.

Is this still about drush on clean install or previous old install with many modules? Drush is not a module, it's CLI shell-based scripting tool.

How could I tell what module is calling user_load(0)?

User Revisions installs and works on new clean Drupal 7 install. BUT, it still breaks drush:

dev@dev /var/www/example.com/htdocs # drush status
Could not login with user ID 0. This is typically caused by importing a MySQL database dump from a faulty tool which re-numbered the anonymous user ID in the users   [error]

With User Revision enabled:

Databas tables:

When trying to open or edit any user page:

Nothing else in dblog, besides 404 reports for user pages and nothing on nginx error.log

Also I just noticed that Views error I posted earlier it refers to a node that has entity reference of a user. So I don't know if it's related.

But if you try to update that entity reference (by e.g. selecting any user) with User Revision enabled:

Problem still persists without entity reference field. No user page can be opened or edited, same error on dblog.

Yes there is entity reference field referring to a node. But it's the 'Simple' entity selection and not a 'View' one.

Sorry, tagged wrong version, I meant 7.x-2.x, both stable and dev.

vibrasphere → created an issue.

vibrasphere → created an issue.

Tried applying same logic from https://www.drupal.org/project/commerce_option/issues/3192150 → but no result.

Getting this with PHP 7.4 too now, but only while deploying new projects, old websites do not produce this error.

Potential/similar fix maybe? https://www.drupal.org/project/drupal/issues/3314719 🐛 Notice: Trying to access array offset on value of type null in _field_write_instance() Needs review

Okay it's not related, the Commerce error can be patched with https://www.drupal.org/project/commerce/issues/3284128#comment-14616806 📌 Required parameter $options follows optional parameter $data in commerce_cart.module on line 1163 Fixed

Now it's just:

Fatal error: Uncaught TypeError: Illegal offset type in isset or empty in /htdocs/includes/theme.inc:421 Stack trace: #0 /htdocs/includes/theme.inc(1150): ThemeRegistry->offsetExists() #1 /htdocs/includes/errors.inc(252): theme() #2 /htdocs/includes/bootstrap.inc(2672): _drupal_log_error() #3 [internal function]: _drupal_exception_handler() #4 {main} thrown in /htdocs/includes/theme.inc on line 421

There are no other errors logged.

Hello, I enabled some extra error logging with

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
$conf['error_level'] = 2;

It shows:

Deprecated: Optional parameter $data declared before required parameter $name is implicitly treated as a required parameter in /htdocs/sites/all/modules/commerce/modules/cart/commerce_cart.module on line 1202

Fatal error: Uncaught TypeError: Illegal offset type in isset or empty in /htdocs/includes/theme.inc:421 Stack trace: #0 /users/htdocs/includes/theme.inc(1150):ThemeRegistry->offsetExists() #1 /htdocs/includes/errors.inc(252): theme() #2 /htdocs/includes/bootstrap.inc(2672): _drupal_log_error() #3 [internal function]: _drupal_exception_handler() #4 {main} thrown in /htdocs/includes/theme.inc on line 421

Is this two separate unrelated errors, or Commerce → error is causing the Drupal core ThemeRegistry error?

vibrasphere → created an issue.

vibrasphere → created an issue.

Ran into this problem because of PHP 8.1 issues with autoload → , dblog spams some error on any page load, could not find any solution or patch so decided to try alternatives.

Steps:

1. Disable autoload. It causes to disable following modules blazy, blazy_ui, slick, slick_fields, slick_extras, slick_views, slick_example, slick_ui
2. Enable xautoload → , but you can only enable blazy, blazy_ui, you cannot enable slick → , it throws errors:
   
   

   WD php: Error: Class 'Drupal\slick\SlickManager' not found in slick() (line 28 of /htdocs/sites/all/modules/slick/slick.module).               [error]
   Error: Class 'Drupal\slick\SlickManager' not found in slick() (line 28 of /htdocs/sites/all/modules/slick/slick.module).

3. Completely disable and uninstall both autoload and xautoload, enable registry_autoload → latest dev version, as of this post it is 7.x-1.x-dev 2023-Feb-28 version.
4. Try to rebuild registry, both with drush rr and using registry_rebuild. Don't forget to clear caches drush cc all.
5. Attempt drush en blazy, blazy_ui, slick, slick_fields, slick_extras, slick_views, slick_example, slick_ui. All modules install no errors.

There's also another autoloader module that is not documented, but is listed when trying to enable blazy with drush psr0 → .

vibrasphere → created an issue.

vibrasphere → created an issue.