🇨🇷Costa Rica @yuvania

I have the same problem as @sheetal.pathak and I couldn't reproduce the error. In my case I used a 10.3.5 environment.

danrod Could you check the change?

yuvania → changed the visibility of the branch 3476884-php-8.2-deprecated to active.

yuvania → changed the visibility of the branch 3476884-php-8.2-deprecated to hidden.

I couldn't recreate the issue on my end. Could you share a screenshot of your current configuration to see if there's any difference?

Thanks for the merge request. I tested it and it works perfectly. Ready to move forward!

I tried it on drupal 10.3 and it worked fine for me

It works, it fixes the issue that did not allow the module to be compatible with drupal 11. https://dev.acquia.com/drupal11/deprecation_status/projects/social_auth_...

It works well

I confirm, I used it yesterday and it worked perfectly.

Reviewed and tested the patch. Everything works as expected.

RTBC +2

yuvania → made their first commit to this issue’s fork.

yuvania → created an issue.

Okay and also check it, it works fine

yuvania → created an issue.

Agree with chandu7929, the changes look good and work well.

yuvania → made their first commit to this issue’s fork.

You could perhaps try using an older version of Drush, such as 12.x, which is known to be stable with Drupal 10.3, to see if that resolves the issue

I've tested the latest changes in my environment and everything seems to be working perfectly. Thanks everyone for the great work!

Maybe you could try breaking down the target_id further in the errorElement function to see if something is being missed in the validation. I'm referring to checking or adjusting the structure of $element before it reaches the check, in case there's any data not being handled correctly

Did you notice if this issue started after an update? You might also want to check the logs and JavaScript console for specific errors, and maybe try disabling the cache temporarily to see if that helps isolate the cause

Good eye on this, I think that fix will help the field_tags look better in the teaser. Thanks for sharing!

To fix the "headers already sent" issue, I added a check in the BigPipe.php file to make sure the headers hadn’t already been sent before printing the content:

if (!headers_sent()) {
    if ($chunk instanceof HtmlResponse) {
        print $chunk->getContent();
    } else {
        print $chunk;
    }
    flush();
} else {
    // You can handle the situation here if the headers have already been sent
}

I also tried wrapping the code in an output buffer to prevent anything from being sent too early, which helped avoid the error:

ob_start();

// Here’s the code that sends the headers or starts a session
if ($chunk instanceof HtmlResponse) {
    print $chunk->getContent();
} else {
    print $chunk;
}
flush();

ob_end_flush();

Hello alexander tallqvist , I tested the patch, and it worked for me.

Hi @aaron.ferris ,

1. I tested the change https://git.drupalcode.org/issue/views_ical-3465114/-/commit/b718fd9d626... where the property vTimezone was added to the style, and it works perfectly. I had considered the same solution, and here's why it makes sense:
2. Avoiding Deprecated Dynamic Properties: By defining the property explicitly in the class, we prevent PHP 8.3's deprecation warnings about dynamic property creation. This keeps our code future-proof and aligns with best practices.
3. Logical Association: vTimezone is intrinsically tied to the style's configuration and state. Placing it within the style ensures that all relevant data and behavior are encapsulated within the appropriate object.
4. Maintaining Functionality: This change preserves the existing functionality and ensures that time zone transitions are correctly managed and applied within the iCal generation.

Thanks for the merge request! It should help maintain compatibility with newer PHP versions while keeping the module's functionality intact.

Hi @droodpal,

I've reviewed the pages and compared the styles, but I wasn't able to reproduce the error. The styles for the problematic page and the one that works correctly seem to be the same.

Here are a few suggestions you might want to consider:

1. Browser Caching: Ensure your browser cache is cleared. Sometimes old styles can be cached and affect how the page is displayed.
2. CSS Specificity: Double-check if there are any specific styles being overridden by other CSS rules. Use browser developer tools to inspect the styles applied to the elements.
3. Custom CSS or JS: Verify if there is any custom CSS or JavaScript that might be interfering with the layout on the problematic page.
4. Responsive Design: Check if there are any media queries or responsive design rules that might be affecting the display on certain screen sizes or devices.
5. Modules and Themes: Ensure that all modules and themes are up to date. Sometimes issues arise from outdated components.
6. Error Logs: Look at the browser console for any errors or warnings that might give a clue about what's going wrong.
7. Class Conflicts: Make sure there are no conflicting class names that might be causing unintended styles to be applied.

Additionally, I'll check if anyone has commented elsewhere on the internet about a similar issue to see if there's a known solution or workaround.

Hope this helps!

Hi @Pemson18,

I've reviewed the discussion, and I'd like to offer a suggestion that might help clarify the process of block instantiation and placement using code in Drupal 10.

From my experience, it is possible to create and place blocks programmatically without using the UI configuration. Here's a basic example of how you might achieve this in an update hook:

use Drupal\block\Entity\Block;

/**
 * Implements hook_update_N().
 */
function mymodule_update_10001() {
  // Create a new custom block.
  $block = Block::create([
    'id' => 'my_custom_block',
    'theme' => 'bartik',
    'plugin' => 'my_custom_block_plugin',
    'settings' => [],
    'visibility' => [],
    'region' => 'sidebar_first',
    'weight' => 0,
  ]);
  $block->save();

  // Ensure the block is placed in the desired region.
  \Drupal::service('theme_handler')->rebuildThemeData();
  \Drupal::service('theme_handler')->refreshInfo();
  $theme = \Drupal::theme()->getActiveTheme();
  $theme_name = $theme->getName();

  // Clear cache to apply changes.
  \Drupal::service('cache.render')->invalidateAll();
}

This code snippet creates a custom block and places it in the 'sidebar_first' region of the 'bartik' theme. Note that you need to adjust 'my_custom_block_plugin' to your actual block plugin ID.

Make sure to clear the cache after running the update hook to see the changes. This approach should bypass the need for UI configuration and ensure that your block is placed directly via code.

I hope this helps clarify the problem! Let me know if you need further clarification or assistance.

Hi @eaajithe,

What an interesting issue! Based on your description, here are a few steps that might help resolve it:

1. Field Configuration: Ensure the email field is set as required in the user entity field settings. Sometimes configurations might change during upgrades.
2. Module Interference: Check if modules like "Password Policy" or others affecting user profiles are causing the issue. Temporarily disable them to test.
3. Permissions: Verify user roles have the necessary permissions to edit and view the email field.
4. Update Hooks: Confirm all update hooks have run correctly after upgrading from Drupal 9 to Drupal 10.
5. Form Display: Check the form display settings to ensure the email field is included.

These steps should help identify the root cause.

Hope this helps!

I've tested the provided patch and observed a significant improvement in the load times for the admin/config page. This change greatly enhances the usability of the configuration page in larger projects.

I agree with the suggestion to run these checks less frequently, such as through a cron job or lazy loading, to ensure we still catch potential issues without affecting performance. Implementing this would provide a balanced approach to maintain site health without compromising speed.

The patch improves the infinite-scroll.js file and the views_infinite_scroll.module to ensure that infinite scrolling works consistently. Changes include:

Adding the once parameter to the JavaScript function to ensure certain behaviors are applied only once per element.
Adjusting the module to attach the views-infinite-scroll library only when AJAX is enabled on a view.

yuvania → created an issue.

yuvania → made their first commit to this issue’s fork.

yuvania → made their first commit to this issue’s fork.

yuvania → made their first commit to this issue’s fork.

I fixed access check errors for D10 compatibility

Patch to resolve compatibilities with drupal 10

yuvania → created an issue.

Patch to resolve Fix phpunit 10 obsolescence

yuvania → created an issue.

Patch to resolve Fix phpunit 10 obsolescence

yuvania → created an issue.

Patch to solve warnings

yuvania → created an issue.

https://www.drupal.org/project/ultimate_cron/issues/3394314#comment-1527... 🐛 Deprecated method implementsHook() Active In this issue, I added a patch that fixes it!

This is a better version than the previous patch. The previous one improved the code but did not solve the problem of the deprecated method: implementsHook()

Patch generated by Upgrade Rector

yuvania → created an issue.

hchonov → credited yuvania → .

Using this patch I solved broken code problems, I leave it here in case anyone needs it

Patch to fix compatibility issues with Drupal 10

yuvania → made their first commit to this issue’s fork.

yuvania → made their first commit to this issue’s fork.

I checked it, it works fine for me.

I checked it, it works fine for me.

You have a point, I checked it, it worked fine for me.

I checked it, it works fine.

You have a point, I checked it, it worked fine for me.

I checked it, it works fine.

Hello, I tried the patch and it works correctly.