crystaldawn → created an issue.
Granted. However I dont have the server API code available. But you should be able to make one just by looking at current code and then you can host your own server. I also added you as a maintainer so you can update the API endpoints.
I found this to be much more effective at finding/fixing bad variables in the variables table:
drush eval '$query = db_query("SELECT name, value FROM {variable}"); while ($variable = $query->fetchObject()) { $value = @unserialize($variable->value); if ($value === FALSE && $variable->value !== serialize(false)) { echo "Variable " . $variable->name . " has serialization issues\n"; } }'
Heh, well I use a bit more than just backtrace. I use xdebug in vscode via breakpoints and I'll tell ya, while it's not difficult, it's VERY time consuming stepping through where the code is going, etc. The task I had to fix this was time limited and this was the best answer I could come up with that I knew would not only fix our current issue, but any future issues as well. If I had the time, I'm 100% confident I could find the root cause and fix that but I still believe this should be handled better in core anyway which is what the patch is meant to assist with. I'm sure someone smarter than me will come along and improve on the patch as it is. At least that's the hope anyway :D But as of right now, it works and thats the bottom line I suppose.
Well I know it applies to d9.5 since that is what we're using and we also know that the problem stems from the migrate module (with no custom modules enabled), but to us it seemed like it made sense to fix it in core because in our limited search we found others having the same exact issue but with differing context (such as this issue queue which I hijacked from taxonomy heh). So yes, we could probably plug 10 holes to stop the leaking, but it makes more sense to just turn off the faucet and close them all at once ;)
How about 10 then? 11 seems a bit to extreme, this is going to be a pretty common problem for migrations once PHP 8 becomes more used. We have 1600+ sites moving from D7 to D9/10 and this would be a problem for the next several years.
Explain why you keep setting this to D11 pls. That will cause it to never be put into 9 or 10 which to me is unacceptable.
This actually affects all versions of D8/9, but since 9.5 is going to become 10 and 10 will become 11, makes sense to keep this as D9.5. This also isnt a support request. It's a bug in core. Good catch on the /a and /b paths, forgot to remove docroot.
Here is a patch that fixes this problem in core when you are using PHP 8.x, in PHP 7.x this is only a warning, not a fatal error but that was changed in PHP 8.x. This problem for us was discovered when trying to use the Migrate module to migrate sites. One of the fixes was to change the ids that were being sent to the proper format (that wasnt possible for us since there was no ID list, it was array[0] = NULL, we have no idea where it came from since it wasnt anything our custom code provided) but core should still be smart enough to handle malformed ids and produce a warning, not a fatal error.
This appears to be a problem with the load() function accepting mixed types when it should only accept an int. If you send it an array, it will have this problem. Many things in drupal core send this an array and it was never a problem. But in PHP 8.x this results in a fatal error.
crystaldawn → created an issue.
Re-roll for 5.1.12
An array containing an array isnt "useless". It sounds to me like you're viewing it as an unused element and that's just not the case. Explain what makes it "useless".
A re-roll is needed to apply to 7.97
Well, the patch in #33 didnt work for us at all. The masquerade block shows up for the admin user, but a normal user who has no access to that block to begin with cannot see the unmasquerade link and we're not about to give them access to the admin toolbar. Would it not make sense to make a 2nd block and a new permission called "unmasquerade" that can then be given to the "authorized user" role?
Erm. Where in the README does it mention anything about a "worker" plugin? It doesnt. I dont even know what you're referring to actually if it's not the drush command provided by the module. The only thing it ever mentions is the enqueue CRON job that comes with the module itself. It also only mentions using Drush to actually run queues and then putting drush on a server cron service. It makes no mention about a cron job that runs a "worker" plugin which would ensure that the queues never fill up with duplicates.
This sounds more like a documentation bug because I absolutely followed the Readme exactly as written. Your comment seems to indicate you dont actually understand the problem I'm describing which is duplication. Whether its a bug or a feature request, thats debatable so I put it as a feature request. The worker you're referring to must be the drush command which isnt a plugin, its a drush command since you mention it's to be run separate from hook_cron. The process you just described where queueing and running the queue via separate process == queue duplication just waiting to bite you in the butt. That's no good. We also dont even want to use drush to run the queue processing anyway. We want the cron job itself to queue and then immediately begin working on the queue so as to reduce the possibility of duplicates (assuming queue process finishes before next enqueue happens via cron). Thats why we had to add our own cron job that runs the code I showed above. That could have been avoided by adding the option I mentioned in the original post (which is the feature request).
So I still see the feature request as still valid if you're not referring to a feature to immediately clear the queue that is created by the CRON job (hook_cron) which is where the duplication problem is coming from that we're seeing in our network and server load stats and it's SIGNIFICANT since we have 1200+ sites (acquia sitefactory which is multisite). If this were a single site on it's own little server somewhere, it probably wouldnt be a problem. Duplicate entries definitely need to be avoided at all costs when working at this scale and I've seen mention of duplication problems in other issue posts in the queue here. So this isnt a problem thats new, it seems to be known.
crystaldawn → created an issue.
crystaldawn → created an issue.
Just in time for the D7 EOL. Impressive. Only took 11yrs to add...... to dev. Trying to figure out of the statement of "Better late than never" actually applies Lol