csmdgl β created an issue.
Seems to be a duplicate of https://www.drupal.org/project/facets/issues/3480004 π TypeError with "show count" facet summary Active . The patch there is a more complete solution.
Re-roll and static patch of #28.
This is not a new bug and has long existed without causing problems for us. It has become apparent by moving to PHP 8.
When enabling a module via drush, this warning is produced:
Undefined array key "php" environment.inc:790 [warning]
By itself, we were tolerating and ignoring the bug. But when enabling a module via the UI, this produces thirteen pages of warnings of these two types:
Warning: Undefined array key "php" in _system_modules_build_row() (line 1027 of /var/www/html/docroot/modules/system/system.admin.inc).
and
Deprecated function: version_compare(): Passing null to parameter #2 ($version2) of type string is deprecated in _system_modules_build_row() (line 1027 of /var/www/awards.practicegreenhealth.org/pgh-awards/docroot/modules/system/system.admin.inc).
Features is corrupting the system module cache with this line in features_get_info()
:
unset($row->info['php']);
Patch attached.
csmdgl β created an issue.
This patch was originally provided by @jenlampton in issue 3060019 π Notice: Undefined index: value in views_handler_filter->accept_exposed_input() Fixed .
csmdgl β created an issue.
csmdgl β created an issue.
I also have this problem. I believe it has something to do with the features module clearing info['php']. It seems like the ctools and context modules are also involved, but I haven't completely tracked it down yet.
New patch for 3.0.0-beta1 for the paging issue.
Rerolled #67 for 10.2.5.
Patch attached this time.
Rerolled #67 for 10.2.5.
Re-rolled #55 for 10.2.5.
csmdgl β created an issue.
In D7, there is a bug in the logic of views_data_export_garbage_collect(). It is calling views_data_export_view_clear() with an array of eids, but views_data_export_view_clear() only works for an individual eid.
Patch attached.
Version of the patch for PHP 7
Step #2 of views_data_export_garbage_collect() function should indeed take care of deleting the temporary files. However, in cases where that delete fails for whatever reason, the file_usage entry is not removed from the database, but the views_data_export entry is. The file_delete() only removes the file_usage if the actual file delete was successful, even when the force parameter is true. The attached patch explicitly removes the file_usage before doing the delete. This will allow system_cron to attempt to delete the stuck expired temporary file without logging an error that it is in use by views_data_export. Additionally, make sure that views_data_export_cron runs prior to system_cron so this garbage collect happens before system_cron.
Patch for 3.0.x
Re-roll #2 for 7.x-2.37
Re-roll #37 for 7.x-2.37.
Re-roll #17 for 7.x-2.8
Re-roll for 7.x-2.x
Patch attached.
csmdgl β created an issue.
Attaching patch. The problem is due to a backward breaking change in call_user_func_array()
. Specifically this change: βIt is a fatal error to have a numeric key in args appear after a string key, or to have a string key that does not match the name of any parameter of callback.β
This patch only does not include the entire js data from $_REQUEST in the arguments array if the php version is >= 8.
csmdgl β created an issue.
csmdgl β created an issue.
csmdgl β created an issue.
Re-rolling #23 for 2.0.0-beta3
Updated patch.
Re-roll for 4.0.1
csmdgl β created an issue.
Test patch in 21 for 2.x-dev
Reroll patch in 17.