First, we need to resolve #3537760
Added some remarks/questions to MR
Performed manual tests for D11, enabled error_page_test and visited the following pages:
/error_page_test/exception: simulates an exception.
/error_page_test/fatal_error: simulates a fatal error.
/error_page_test/user_error: simulates a user error.
/error_page_test/php_notice: simulates a PHP notice.
Looks fine
Removed _TARGET_DB_VERSION in order to simplify
We do not set TARGET_CORE in our configuration.
I think this is a template infrastructure issue on Drupal.org's side. The warning will disappear once they complete the migration and remove all internal references to _TARGET_CORE from their CI templates.
Please update ticket description and explain the fix.
I have enabled module on D11, next I have updated settings with
`
// Only if you don't use composer.
require_once 'modules/custom/error_page/src/ErrorPageErrorHandler.php';
set_error_handler(['Drupal\error_page\ErrorPageErrorHandler', 'handleError']);
set_exception_handler([
'Drupal\error_page\ErrorPageErrorHandler',
'handleException',
]);
// Log the UUID in the Drupal logs.
$settings['error_page']['uuid'] = TRUE;
`
what generated a fatal error on homepage
`
Fatal error: Cannot redeclare _drupal_error_handler_real() (previously declared in /var/www/html/web/core/includes/errors.inc:57) in /var/www/html/web/.../error_page/errors.inc on line 78
`
I don’t see a "Skip" button in the UI.
I assume that we need to add a button that will allow the user to change the active value for the selected row.
Manual testing completed. No issues found. Code appears stable and ready for merge.
Performed manual testing to verify JavaScript behavior.
Confirmed that auto-submit is triggered when:
* Pressing Enter
* Selecting a date from the calendar picker
Added BabelHookOrder as separate class to avoid class loading issues on Drupal 10
alorenc → changed the visibility of the branch 3533695-convert-procedural-hook to hidden.
The merge request (MR) introduces an even more specific query, highlighting additional issues with database abstraction. Perhaps we should change our approach and focus exclusively on issue 3535768, replacing the JSON column.
I have added remarks to MR
Updated the test to use a language that doesn't have a formula.
yes, let's focus on resolving a specific issue.
For PHPCS issues, I have created ticket #3535417.
I have performed manual tests, records were added/removed from the Babel tables.
Added remarks to MR
Got a fatal error
The website encountered an unexpected error. Try again later.
AssertionError: assert($source instanceof Source) in assert() (line 42 of modules/repos/babel/src/BabelService.php).Drupal\babel\BabelService->update() (Line: 58)
babel_js_alter() (Line: 472)
It works for me, but there is a question regarding the supported Drupal version.
thanks, it looks fine
The function field_group_remove_empty_form_groups expects that groups are ordered from parent to child
Added an additional function which orders groups.
Updated to 'drupal/field_group:^4.0'
I was able to replicate the issue consistently.
I created the following nested group hierarchy:
- Level 1 (parent of Level 2)
- Level 2 (parent of Level 3)
- Level 3 (contains the body field)
I then reorganized the structure using the Field Group UI:
- Level 3 becomes the top-level group
- It contains Level 2
- Which contains Level 1
- And Level 1 contains the body field
I exported the configuration and noticed. The weight values were correctly updated. However, the field order in the YAML config remained unchanged, still reflecting the original nesting order.
It looks like the Field Group module builds the field group hierarchy based on the order of items in the YAML configuration file, instead of relying solely on the weight and parent_name properties.
This becomes problematic when reversing the hierarchy (e.g., changing a parent into a child or vice versa), because:
* The updated structure is not respected during render
* Fields and groups may not display correctly, even if weight and parent_name appear valid
Tested 2 scenarios: with inline form errors and without inline form errors.
Both look good.