Wolsztyn, 🇵🇱
Account created on 31 January 2019, over 6 years ago
#

Merge Requests

More

Recent comments

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

First, we need to resolve #3537760

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc created an issue.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Removed _TARGET_DB_VERSION in order to simplify

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc created an issue.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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
`

🇵🇱Poland alorenc Wolsztyn, 🇵🇱
🇵🇱Poland alorenc Wolsztyn, 🇵🇱
🇵🇱Poland alorenc Wolsztyn, 🇵🇱
🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Manual testing completed. No issues found. Code appears stable and ready for merge.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Performed manual testing to verify JavaScript behavior.
Confirmed that auto-submit is triggered when:
* Pressing Enter
* Selecting a date from the calendar picker

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Added BabelHookOrder as separate class to avoid class loading issues on Drupal 10

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc changed the visibility of the branch 1.x-3533695 to hidden.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc changed the visibility of the branch 3533695-convert-procedural-hook to hidden.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

I have added remarks to MR

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Updated the test to use a language that doesn't have a formula.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc made their first commit to this issue’s fork.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

yes, let's focus on resolving a specific issue.
For PHPCS issues, I have created ticket #3535417.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc created an issue.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc created an issue.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

I have performed manual tests, records were added/removed from the Babel tables.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱
🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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) 
🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc created an issue.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

It works for me, but there is a question regarding the supported Drupal version.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱
🇵🇱Poland alorenc Wolsztyn, 🇵🇱

thanks, it looks fine

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

The function field_group_remove_empty_form_groups expects that groups are ordered from parent to child
Added an additional function which orders groups.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Updated to 'drupal/field_group:^4.0'

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc made their first commit to this issue’s fork.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

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

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

alorenc made their first commit to this issue’s fork.

🇵🇱Poland alorenc Wolsztyn, 🇵🇱

Tested 2 scenarios: with inline form errors and without inline form errors.
Both look good.

Production build 0.71.5 2024