🇮🇳India @mdsohaib4242

Ensure your database and tables use the utf8mb4 character set and the utf8mb4_general_ci collation.

Run the following SQL command to check the collation

SHOW VARIABLES LIKE 'collation_database';

Update the database collation to utf8mb4_general_ci

ALTER DATABASE your_database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

For the config table and other relevant tables, update the collation

ALTER TABLE config CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
ALTER TABLE config CHANGE name name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Specify utf8mb4 during the installation process.
Make sure to add the following to your settings.php inside the database connection.

    'collation' => 'utf8mb4_general_ci',

The error might be caused by a bug in version 8.x-3.25.
Update the Bootstrap theme to the latest stable version

composer require drupal/bootstrap:^3.26

This error occurs when Drupal is unable to correctly load a theme extension due to a missing or misconfigured theme. It seems that when you switch between branches, the system might be losing track of the theme information, causing the addTheme() method to receive a null value instead of a valid theme object.

Since Drush is stuck try to delete the cache tables directly from the database

DELETE FROM cache;
DELETE FROM cache_config;
DELETE FROM cache_data;

If the theme was added via the drupal_themes table, ensure that the theme is still registered in the system after switching branches. You can manually add the theme or clear its configuration from the database or rebuild the theme registry manually.

drush config:import

To resolve this, you need to ensure that your custom process callback is added while preserving the existing callbacks. Modify your my_module_field_widget_form_alter function to append the custom callback to the existing #process array, rather than replacing it.

function my_module_field_widget_form_alter(&$element, \Drupal\Core\Form\FormStateInterface $form_state, $context) {
  if ($context['items']->getFieldDefinition()->getName() !== 'field_tags') {
    return;
  }
  
  if (isset($element['#process'])) {
    $element['#process'][] = '_my_module_field_widget_form_process';
  }
  else {
    $element['#process'] = ['_my_module_field_widget_form_process'];
  }
}

You could try checking for any existing conflicts in composer.json

composer why guzzlehttp/guzzle

If a specific package is requiring an incompatible version of Guzzle, update it to a version that is compatible with guzzlehttp/guzzle ~7.9.2 or you could Temporarily remove conflicting dependencies then proceed with the Drupal upgrade.

If there are no conflicting packages

composer require guzzlehttp/guzzle:~7.9.2 --update-with-all-dependencies

Then retry the upgrade command for Drupal core.

You can check this out.

https://www.tag1consulting.com/blog/migrating-your-data-drupal-7-drupal-...

You can confirm that if you are using a development version by running this command

composer show drupal/recommended-project

If you see dev-main, it confirms that you are using a development version.

To switch to a stable release, run:

composer require drupal/recommended-project:^10.1 --no-update

composer update

Then you need to update your composer.json to allow a broader range for chi-teck/drupal-code-generator:

composer require chi-teck/drupal-code-generator:^3.5 || ^4.0 --no-update

Then update Drush to the latest stable version:

composer require drush/drush:^12 --no-update

You can check the $_SERVER headers to see if the real IP address is passed via headers like X-Forwarded-For or HTTP_X_FORWARDED_FOR.
At last check for the REMOTE_ADDR if no valid IP was found

To debug this issue

• Look at the page you’re trying to save (node 3916). See if any fields contain links, as they might be causing the issue.
• See if any links are being added incorrectly. Links should be rendered properly, not passed like as objects.
• There might be code that outputs a Link object (using \Drupal\Core\Link) without rendering it properly (using ->toString() or ->getUrl()->toString()).

To handle the error when $options is NULL in buildUrl(), you can add a simple check to ensure that $options is always an array.
Something like this

$options = is_array($options) ? $options : [];

Try turning off aggregation in the settings.php file

$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;

Or a workaround would be to manually search and delete the .js file.

To simplify the solution, we can focus directly on collecting error messages for each field without using an index. Instead, we’ll gather each violation message into an array for the field and then concatenate them when setting the error.

• We skip indexing and directly store each violation message under $form_element_name.
• Each field's error messages are combined into a single string in one step with implode(' ', $messages).

To fix this issue, update Toolbar.js to first check if #toolbar-administration actually exists before trying to apply any classes to it. This way, the script won’t attempt to modify elements that aren’t there, something like this

const toolbarElement = document.querySelector('#toolbar-administration');
if (toolbarElement && isOriented) {
  toolbarElement.classList.add('toolbar-oriented');
}

You need to make sure that JavaScript behaviours are reattached after the AJAX callback. You can do this by ensuring that the ajax['callback'] method returns the form correctly.

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

class AjaxStatesForm extends FormBase {

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'ajax_states_form';
  }

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    $form['js_states_test'] = [
      '#type' => 'details',
      '#open' => TRUE,
      '#prefix' => '<div id="js_states_test_wrapper">',
      '#suffix' => '</div>',
    ];

    $form['js_states_test']['reload'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Check me to reload Select Field field'),
      '#ajax' => [
        'callback' => '::buildAjax',
        'wrapper' => 'js_states_test_wrapper',
      ],
    ];

    $form['js_states_test']['select_field'] = [
      '#type' => 'select',
      '#title' => $this->t('Select Field'),
      '#options' => [0 => 0, 1 => 1],
      '#default_value' => 0,
      '#ajax' => [
        'callback' => '::buildAjax',
        'wrapper' => 'js_states_test_wrapper',
        'event' => 'change', 
      ],
    ];

    $form['js_select_field_textfield'] = [
      '#type' => 'textfield',
      '#title' => $this->t('This field should show when 1 is selected in Select Field'),
      '#states' => [
        'visible' => [
          ':input[name="select_field"]' => ['value' => 1],
        ],
      ],
    ];

    $form['#attached']['library'][] = 'core/drupal.ajax';

    return $form;
  }

  /**
   * AJAX callback to rebuild the form section.
   */
  public function buildAjax(array &$form, FormStateInterface $form_state) {
    return $form['js_states_test'];
  }

  /**
   * {@inheritdoc}
   */
  public function submitForm(array &$form, FormStateInterface $form_state) {
  }
}

This approach ensures that #states are reattached correctly after the form is reloaded via AJAX.

The `spaceless` filter in Twig was deprecated as of version 3.12. To address this deprecation, you should remove the `spaceless` filter from your Twig templates. Instead, rely on HTML minification tools, like AdvAgg or HTML Minifier, or front-end build tools to minimize whitespace in your output. Additionally, CSS can be used to manage whitespace rendering. Removing the filter ensures compatibility with future Twig versions.

Yes, the warning is generated because of an issue in the image file itself. Specifically, it indicates that the PNG image contains invalid or multiple ICC color profiles.

This worked for me!

It would be safer to keep the method and just remove the condition, turning it into a getter. This way, you avoid the risk of breaking contrib or custom modules that might rely on it. By keeping it as a getter, you ensure backward compatibility.

/**
 * Returns the typed config manager service.
 *
 * @return \Drupal\Core\Config\TypedConfigManagerInterface
 *   The typed config manager service.
 */
protected function typedConfigManager(): TypedConfigManagerInterface {
  return $this->typedConfigManager;
}

This will make sure your modules continue to work seamlessly without any unexpected breaks. Does this give you a bit more confidence in your change?

Using scrollIntoView() could be a better option here, especially if you have fixed headers or other elements that might obscure the view. It allows you to specify options for more control, like:

element.scrollIntoView({
  behavior: 'smooth',
  block: 'start',
  inline: 'nearest'
});

Your CSS can define the scroll offset like you mentioned:

[data-once="ajax-pager"] {
  scroll-margin-top: 5rem;
}

That JavaScript block recursing up the DOM to find the scrollable object seems to be a workaround that might no longer be necessary with scrollIntoView()

You can use pngcrush to remove unwanted metadata from PNG images

1. Install pngcrush
2. Run command - pngcrush -rem allb -out output.png input.png

This patch will allow null values for $message and replace them with a default message ('An error occurred.') if null is encountered, ensuring the method behaves as expected.

This should prevent the error you're facing and provide a safe fallback when the field definition isn't available.

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

You can use the null coalescing operator (??) to set a default empty string in case getValue('name') returns null

Instead of:

$mock = $this->getMockForAbstractClass(EntityLink::class);

You can use PHPUnit's mocking framework like this:

$mock = $this->createMock(EntityLink::class);

This creates a mock object of EntityLink without relying on getMockForAbstractClass().

A more efficient approach would be to proceed with the migration from Drupal 7 to Drupal 10 as it is. Once the migration is complete, you can create a new "telephone" field in Drupal 10 and then transfer the data from the old field to the new one.

For example, if your content type is "article," and your existing field is `field_old` while the new telephone field is `field_new`, you can use a script to copy all the data.

$batch_size = 50;
$nids = \Drupal::entityQuery('node')
  ->condition('type', 'article')
  ->execute();
$nids_batches = array_chunk($nids, $batch_size);

foreach ($nids_batches as $batch) {
  $article_nodes = \Drupal\node\Entity\Node::loadMultiple($batch);

  foreach ($article_nodes as $article_node) {
    if (!$article_node->get('field_old')->isEmpty()) {
      $article_node->set('field_new', $article_node->get('field_old')->getValue());

      $article_node->save();
    }
  }
}

This worked for me.

// Check if $languages is an array before using array_values()
$languages = $settings->get('languages');
if (is_array($languages)) {
    $languages = array_filter(array_values($languages), function($l) {
        return !empty($l);
    });
} else {
    $languages = [];
}

My error :-

Drupal\Core\File\Exception\FileWriteException: Temporary file 'temporary://fil29E3.tmp' could not be created. in Drupal\Core\File\FileSystem->saveData() (line 521 of core\lib\Drupal\Core\File\FileSystem.php).

My solution :-

1. Created a "temporary" folder in \sites\default\files.

2. Attached the path in settings.php $settings['file_temp_path'] = 'sites/default/files/temporary';