🇮🇳India @kalpanajaiswal

I'm still relatively new to contributing to core, but I’ve been trying to understand this issue and the potential risks around unserialize() and serialized field storage.
Please feel free to correct or improve them:

1. Add a Warning in FieldItem Schema
Since 'serialize' => TRUE can be risky, we could document something like the following in FieldItemInterface::schema():

When using 'serialize' => TRUE, the FieldItem class must ensure only safe values (such as arrays or scalars) are stored. Arbitrary PHP objects should not be serialized.

2. Use allowed_classes in unserialize()
Wherever unserialize() is used (for example, in SqlContentEntityStorage::mapFromStorageRecords()), it might be safer to include:

unserialize($data, ['allowed_classes' => false]);

Alternatively, we could use a limited allowlist of known-safe classes to prevent PHP object injection vulnerabilities.

3. Deprecate Unrestricted unserialize() Usage
We could consider marking all usages of unserialize() without the allowed_classes parameter as @deprecated, and encourage the use of a safer wrapper function or utility.

4. Add a PHPCS Rule
A PHPCS rule could help identify unsafe uses of unserialize() during development—similar to how we detect unsafe render arrays.

5. Audit Use of 'serialize' => TRUE in Core and Contrib
It might be worth reviewing all field types in core and contrib that use 'serialize' => TRUE, to ensure they are not accepting object instances via setValue() or unsafe API data.

Future replacement step
Replace with a Service-based System
In the long term, replace the dynamic *_last_viewed() fallback with a proper service-based system:

Introduce a LastViewedTimestampProviderInterface.

Allow entity-type-specific services using tagged service discovery (e.g., for nodes, media, custom entities).

Make the logic injectable, overrideable, and fully testable — following modern Drupal architecture.
Example

$timestamp = $this->lastViewedManager->getLastViewedTimestamp($entity);

Where lastViewedManager is a new core service that aggregates entity-type-specific providers.

A MR raised to add the deprecation message.
Deprecate Procedural Fallback (This Issue) DONE
Add an @trigger_error() deprecation when function_exists() returns TRUE.

This will alert contrib and custom module developers that they need to stop using *_last_viewed() functions before Drupal 12.

No behavior change yet — just the deprecation message.

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

Error: Call to undefined method Drupal\external_entities\ExternalEntityStorage::getTableMapping() in Drupal\xntt_views\Plugin\views\field\ExternalEntityField->getTableMapping() (line 672 of /var/www/html/modules/contrib/external_entities/modules/xntt_views/src/Plugin/views/field/ExternalEntityField.php).

Issue Trace:

#0 /var/www/html/modules/contrib/external_entities/modules/xntt_views/src/Plugin/views/field/ExternalEntityField.php(130): Drupal\xntt_views\Plugin\views\field\ExternalEntityField->getTableMapping()
#1 /var/www/html/core/modules/views/src/Plugin/views/style/Table.php(146): Drupal\xntt_views\Plugin\views\field\ExternalEntityField->clickSort()
#2 /var/www/html/core/modules/views/src/ViewExecutable.php(1353): Drupal\views\Plugin\views\style\Table->buildSortPost()
#3 /var/www/html/core/modules/views/src/ViewExecutable.php(1452): Drupal\views\ViewExecutable->build()
#4 /var/www/html/core/modules/views/src/ViewExecutable.php(1516): Drupal\views\ViewExecutable->execute()
#5 /var/www/html/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2504): Drupal\views\ViewExecutable->render()
#6 /var/www/html/core/modules/views/src/ViewExecutable.php(1724): Drupal\views\Plugin\views\display\DisplayPluginBase->preview()
#7 /var/www/html/core/modules/views_ui/src/ViewUI.php(627): Drupal\views\ViewExecutable->preview()
#8 /var/www/html/core/modules/views_ui/src/ViewPreviewForm.php(63): Drupal\views_ui\ViewUI->renderPreview()
#9 /var/www/html/core/lib/Drupal/Core/Entity/EntityForm.php(107): Drupal\views_ui\ViewPreviewForm->form()
#10 /var/www/html/core/modules/views_ui/src/ViewFormBase.php(42): Drupal\Core\Entity\EntityForm->buildForm()
#11 [internal function]: Drupal\views_ui\ViewFormBase->buildForm()
#12 /var/www/html/core/lib/Drupal/Core/Form/FormBuilder.php(528): call_user_func_array()
#13 /var/www/html/core/lib/Drupal/Core/Form/FormBuilder.php(370): Drupal\Core\Form\FormBuilder->retrieveForm()
#14 /var/www/html/core/lib/Drupal/Core/Form/FormBuilder.php(625): Drupal\Core\Form\FormBuilder->rebuildForm()
#15 /var/www/html/core/lib/Drupal/Core/Form/FormBuilder.php(321): Drupal\Core\Form\FormBuilder->processForm()
#16 /var/www/html/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm()
#17 [internal function]: Drupal\Core\Controller\FormController->getContentResult()
#18 /var/www/html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#19 /var/www/html/core/lib/Drupal/Core/Render/Renderer.php(633): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#20 [internal function]: Drupal\Core\Render\Renderer::Drupal\Core\Render\{closure}()
#21 /var/www/html/core/lib/Drupal/Core/Render/Renderer.php(634): Fiber->start()
#22 /var/www/html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
#23 /var/www/html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#24 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(183): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#25 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#26 /var/www/html/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#27 /var/www/html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#28 /var/www/html/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#29 /var/www/html/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#30 /var/www/html/core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#31 /var/www/html/core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass()
#32 /var/www/html/vendor/asm89/stack-cors/src/Cors.php(53): Drupal\page_cache\StackMiddleware\PageCache->handle()
#33 /var/www/html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Asm89\Stack\Cors->handle()
#34 /var/www/html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#35 /var/www/html/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(53): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#36 /var/www/html/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#37 /var/www/html/core/lib/Drupal/Core/DrupalKernel.php(715): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#38 /var/www/html/index.php(19): Drupal\Core\DrupalKernel->handle()
#39 {main}

kalpanajaiswal → created an issue.

Drupal Views core was built assuming Sql::$orderby is public.
If query plugin replaces the default one and doesn’t declare it (or keeps it protected), this line fails:

$this->view->query->orderby

in ExposedFormPluginBase::query() (line 160)

Problem:
protected array $orderby;
Core Views expects this to be public because it accesses it directly from outside (e.g., in ExposedFormPluginBase::query()).

Fix:
public array $orderby = [];
Also initialize it to an empty array to avoid undefined property errors when using null coalescing: foreach ($this->orderby ?? []).

$fields should be public
Core plugins may access $fields too, e.g., during rendering or sorting.

public array $fields = []

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

In Drupal, taxonomy terms do not have a built-in uid (owner) field by default.
So, to get the owner ID of a term, we need to first ensure that term entity has a uid field added.

Would you mind sharing additional steps and context to help us accurately reproduce the issue?

This issue does not appear in the Drupal 11 environment.

new TwigFilter('truncate', [Unicode::class, 'truncate']),

Twig Tweak is not implementing its own truncate() logic, but is delegating to:

\Drupal\Component\Utility\Unicode::truncate()

we can wrap it in custom method and safely cast or normalize input before it goes into Unicode::truncate().

I was unable to replicate the reported issue. After performing a fresh setup and adding a plain text field, it displayed correctly within the attribute.

kalpanajaiswal → created an issue.

I have created a patch to adda warning.

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

We're unable to reproduce the issue as described. Could you please provide additional details and clear steps to help us replicate the error?

We encountered a similar requirement, and the following solutions worked effectively in our case:

Including unpublished nodes in the Search API index
Solution: Disable the Entity status processor in the index configuration. This ensures that unpublished nodes are not excluded during indexing.

Excluding unpublished taxonomy terms from facet filters
Solution: Implement a custom Facets Processor plugin that filters out unpublished taxonomy terms during the facet build process. This allows only published terms to be displayed in the facet options, ensuring a clean and relevant user interface.

<?php

namespace Drupal\facets\Plugin\facets\processor;

use Drupal\facets\FacetInterface;
use Drupal\facets\Processor\ProcessorPluginBase;
use Drupal\facets\Processor\BuildProcessorInterface;
use Drupal\taxonomy\Entity\Term;

/**
 * @FacetsProcessor(
 *   id = "exclude_unpublished_terms",
 *   label = @Translation("Exclude unpublished terms"),
 *   description = @Translation("Removes unpublished taxonomy terms from facet options."),
 *   stages = {
 *     "build" = 50
 *   }
 * )
 */
class ExcludeUnpublishedTerms extends ProcessorPluginBase implements BuildProcessorInterface {

  /**
   * {@inheritdoc}
   */
  public function build(FacetInterface $facet, array $results): array {
    $filtered = [];
    foreach ($results as $result) {
      $tid = $result->getRawValue();
      $term = Term::load($tid);
      if ($term && $term->isPublished()) {
        $filtered[] = $result;
      }
    }
    return $filtered;
  }

}

?>

We encountered a similar requirement, and the following solutions worked effectively in our case:

Including unpublished nodes in the Search API index
Solution: Disable the Entity status processor in the index configuration. This ensures that unpublished nodes are not excluded during indexing.

Excluding unpublished taxonomy terms from facet filters
Solution: Implement a custom Facets Processor plugin that filters out unpublished taxonomy terms during the facet build process. This allows only published terms to be displayed in the facet options, ensuring a clean and relevant user interface.

<?php

namespace Drupal\facets\Plugin\facets\processor;

use Drupal\facets\FacetInterface;
use Drupal\facets\Processor\ProcessorPluginBase;
use Drupal\facets\Processor\BuildProcessorInterface;
use Drupal\taxonomy\Entity\Term;

/**
 * @FacetsProcessor(
 *   id = "exclude_unpublished_terms",
 *   label = @Translation("Exclude unpublished terms"),
 *   description = @Translation("Removes unpublished taxonomy terms from facet options."),
 *   stages = {
 *     "build" = 50
 *   }
 * )
 */
class ExcludeUnpublishedTerms extends ProcessorPluginBase implements BuildProcessorInterface {

  /**
   * {@inheritdoc}
   */
  public function build(FacetInterface $facet, array $results): array {
    $filtered = [];
    foreach ($results as $result) {
      $tid = $result->getRawValue();
      $term = Term::load($tid);
      if ($term && $term->isPublished()) {
        $filtered[] = $result;
      }
    }
    return $filtered;
  }

}

?>

Updated the MR with minimum Drupal compatible version to support attribute discovery.
Please review.

Thank you!

MR has been raised and ready for review.

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

Created an MR, ready for review.

kalpanajaiswal → changed the visibility of the branch 3453922-sort-the-option to active.

README.md file has been created and ready for review.

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

kalpanajaiswal → changed the visibility of the branch 3453922-sort to hidden.

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

Raised the MR with condition.

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

Rerolled the patch for contrib module only.

MR https://git.drupalcode.org/project/drupal/-/merge_requests/8325 has been updated against 11.x

As per the suggestion .gitlab-ci.yml is removed from the commit.

Both Patch and MR have been created to address the issue.

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

kalpanajaiswal → changed the visibility of the branch 3454448-add-btn-block-config to active.

Hi Diwakar,
I have updated the Readme file as per the standards.

MR created to sort the $handlers_options in EntityReferenceItem::fieldSettingsForm().

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

I've been working on replicating this locally, and I believe it's functioning as expected after addressing other issues in the queue.
After looking into the issue " https://www.drupal.org/project/search_api_autocomplete/issues/3024266 ✨ Avoid multiple results for the same keyword Needs work "
The goal is to eliminate duplicate suggestions.

The specific question I have is regarding keywords that appear in both lowercase and uppercase.
For example, if we have "Backup" and "BACKUP," should the suggestions include both "backup" and "BACKUP," or just "backup"?
This needs to be aligned with the fix for issue 3024266.

I couldn't find a specific option to enable case-sensitive suggestions. However, if we want the suggestions to be case-sensitive, then the results should also be case-sensitive.

MR https://git.drupalcode.org/project/drupal/-/merge_requests/8398 created for the issue.

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

The issue is not reproducible.
I have tested the feature with Drupal 10.2.7 & search_api_autocompleteVersion: 8.x-1.8 version.
Adding few screenshots for help.

I tried to replicate the issue but it didn't reproduce.
Drupal version: 10.2.7
office_hours module version: 1.17.0

Adding few screenshots after testing in my local setup.

MR has been created and covering all the points mentioned in remaining tasks.

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

MR created to replace readme.txt file to readme.md file.

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

MR created to replace readme.txt file to readme.md file.

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

Created a MR
MR: https://git.drupalcode.org/project/drupal/-/merge_requests/8325

  /**
   * The fields on which to sort.
   *
   * @var array
   */
  protected $fields;

  /**
   * Constructs a new Sort object.
   *
   * Takes an array of sort fields. Example:
   *   [
   *     [
   *       'path' => 'changed',
   *       'direction' => 'DESC',
   *     ],
   *     [
   *       'path' => 'title',
   *       'direction' => 'ASC',
   *       'langcode' => 'en-US',
   *     ],
   *   ]
   *
   * @param array $fields
   *   The entity query sort fields.
   */
  public function __construct(array $fields) {
    $this->fields = $fields;
  }

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

First param comment updated as per the parent class

If you have an entity with a moderation state and want to run the scheduler on entity based on a moderation state.
It will not support.
For example add an article with a scheduler on to be published in future.
But if someone made any changes and moderation state updated in draft mode, it shouldn’t be published.

Here is the thing.
If you look in to the file "inline_entity_form/src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php"
Inside function "formElement"
A piece of code written to call the theme hook for each referenced entity.

$element['entities'] = [
      '#tree' => TRUE,
      '#theme' => 'inline_entity_form_entity_table',
      '#entity_type' => $target_type,
];

For example if we have 1000 reference entity, this theme hook be called 1000 times and due to this process is gets slow.

Just remove the '#theme' attribute and test the functionality.
UI will be broken as theme is not there but process will me much faster.

We faced the same issue and remove the '#theme' and handled broken UI separately

I am adding a screenshot for help.
I have just run a test with 25 reference entity, so there is nut much difference in loading time, but if you test this with more entity reference content like 200 or 300, you will see a huge difference.

Create an MR with patch #11
MR: https://git.drupalcode.org/project/drupal/-/merge_requests/8311

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

Merge request created to add the comment on construct object.
MR: https://www.drupal.org/project/drupal/issues/3450567 🐛 GenerateTheme::__construct() does not document its parameters Active

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

A patch has been created to solve the issue.

kalpanajaiswal → changed the visibility of the branch 3103334- to hidden.

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

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

Created a MR for Drupal 11.
MR: https://git.drupalcode.org/project/drupal/-/merge_requests/8299
Branch: 2951487-check-instance-type

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

Created a MR from patch #6
MR: https://git.drupalcode.org/project/drupal/-/merge_requests/8297
Branch: 3353388-type-error-implode

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

Created one MR from patch 2.
Branch: 3424320-invalidargumentexception-issue

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

I tried all the above mentioned steps and below are the response.

When I visit "/fr/admin/content'
One popup came, I selected english

I refreshed the page and now I selected french

I tried to change "Содержимое" to another the word.
Value is getting updated on "/admin/structure/types/manage/page/fields/node.page.body" page.
Even success message it printing right value.
But its not visible on other pages like "/admin/structure/types/manage/page/form-display",
"/admin/structure/types/manage/page/display",
"/node/add/page".

Its still showing the old value instead of new.
Looks like issue now.

I replicated the same behavior in Drupal 9.5.11 as well.

The issue is not reproducible in Drupal 10.2.6
Feature is working as expected, adding few screenshots for help.

The issue is not reproducible in 10.2.6.
Functionality is working as expected adding screenshots for help.

Converted Editor plugin discovery to attributes.