🇺🇸United States @NicholasS

This can't be applied to the 1.1.x branch right? Hitting this as well would love to test the patch but our site is running 1.1.4

nicholass → created an issue.

@kevin let me know if that works, we actually needed a bulk check feature as well, so well just make custom file views to do this.

Great so I added View Bulk Operation Support, so on a view that is created from a files base table such as the default /admin/content/files you can now add a bulk operations field to it, then be able to adjust the view as you need, and bulk queue pdfs, which are then processed on cron runs.

@trackleft2 - Just to let you know looks like the performance improvements were somehow lost recently.

Oh so I see there is a new "SearchStax PDF Extraction" method in the dropdown, but it asks for an endpoint and token, I don't see a solr extraction endpoint on my "All APIs" (only search and Autosuggest) so maybe this is a feature that is not quite ready yet.

So I tried this out today, switch from 1.7 to 1.8 but its not working when I attempt to set Search API Attachments to SearchStax

So testing out the patch on 1.7 and 1.8, both code bases the patch applies but I get the following error after clicking migrate

Drupal\searchstax\Exception\SearchStaxException: Client error: `GET https://app.searchstax.com/api/rest/experience-manager/v1/studio-languages?appId=5328` resulted in a `403 Forbidden` response: {"detail":"You do not have permission to perform this action.","message":"You do not have permission to perform this act (truncated...) in Drupal\searchstax\Exception\SearchStaxException::fromPrevious() (line 53 of /var/www/html/docroot/modules/contrib/searchstax/src/Exception/SearchStaxException.php).

Or downgrade to token 1.15 as a workaround

See #3548518 as I think it patches the issue discovered here with this module.

This change seems to have caused an issue with a module like add_child_page maybe one of you can review the fix at https://www.drupal.org/project/token/issues/3548518 →

nicholass → created an issue. See original summary → .

#8 stands out https://www.drupal.org/project/token/issues/3511768#comment-16170385 📌 Avoid incorrect and unecessary menu_link_content entity saving Active

I think its the result of token being updated https://www.drupal.org/project/token/releases/8.x-1.16#:~:text=%5B%23351... →

Also getting this on 2.0.5

I am testing on the 3.0x branch, but with the attached patch with the searchstax module the best bets feature now works correctly. But I did have to do the following.

/admin/config/search/searchstax - Uncheck Re-route searches through SearchStudio
/admin/config/search/search-api/server/searchstax_server/edit - Uncheck Retrieve highlighted snippets

Going to close since it looks like I got a patch working on the Best Bet side of things, I did have to disable highlighting and Re-route searches through SearchStudio on my searchstax server and settings, but Best Bets now works correctly and will pin a result to the top of search for the terms its configured for.

My work around has been to composer require 1.7.1, then run migration steps, then update to 1.7.2 after I migrate to fix the SOLR config warnings I get which 1.7.2 fixes.

Would you guys be against a patch to add support for it?

I think the bug lies in the Best Bets module so will open an issue there https://www.drupal.org/project/search_api_best_bets/issues/3548224 🐛 Add support for SearchStax Active

nicholass → created an issue.

@Kevin - I am going to being working on this, I think I will create a VBO plugin to allow different processing options to the selected files. Just curious your comment about the scan of files, and not being able to re-scan them due to the file hash. Why would you want to re-scan the file if the content did not change? If the file is the same the report would be the same.

Looks like the work around is to "process locally" for the search index processors settings (at the bottom) /admin/config/search/search-api/index/______/processors

nicholass → created an issue.

So as usage continues turning off streaming helps but does not fully fix the issue, users still occasionally experience this issue.

See ref. issue this change broke the migration form for users with only 1 account in 1.7.2 I think.

All of this stems from #3539475 I think from adding multiple account support, and I only have 1 account.

So with this current patch I can get to the form to select "SearchStax app to which to migrate" but can't get past it both refresh and submit create errors.

The website encountered an unexpected error. Try again later.

TypeError: Drupal\searchstax\Service\Api::getApp(): Argument #1 ($account) must be of type string, null given, called in /var/www/html/docroot/modules/contrib/searchstax/solr_to_searchstax_ss_migration/src/Form/MigrateServerForm.php on line 777 in Drupal\searchstax\Service\Api->getApp() (line 220 of modules/contrib/searchstax/src/Service/Api.php).
Drupal\solr_to_searchstax_ss_migration\Form\MigrateServerForm->validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 82)

I think it because in SearchStax I only have one account?

nicholass → created an issue.

WORKAROUND SOLUTION: The temp fix does seem to be to set the "always build output: yes" for the view fields, this has not caused any to go blank yet. I guess our site will just have to keep that option on for the time being.

So to report back the patch did not help. We setup hourly automated cypress tests to test all of our 83 pages that use paragraphs that have viewfields. And after this patch we still had one disappear on us. For some reason its only a few that keep going out on us, but longer we let the cache sit the more go empty, over night I think we got up to 4 empty views.

Going to try the "always build output: yes" formatter setting to see if that helps.

Clarify title since I think I know what is going on as I experiment more with it.

Fixed issue headline to be more accurate

Update: Removing the view cache still did not help, the view disappeared again, so I guess I am going to try out this patch to see if it helps.

Update: Removing the exposed filter made no diff, it disappeared on me again. So Resorted to turning caching completely off for the view as a temp work around to see if that does the trick over time.

So any ideas on any what kind of data I can get off prod to help debug if/when this happens again? I tried the database but its seems Acquia dumps the cache tables automatically so I wasn't able to inspect the cache the latest time it disappeared.

Today I am going to try to remove the exposed filters to see if that helps or not.

More background since I was never able to reproduce. Were on Acquia, with varnish/memcache on core 10.5.1 with paragraphs that have a view ref field, adding no amount of ?query params to the page made the view get restored. Only thing that ever worked was editing the page or clearing caches. We use uptimerobot to monitor the view for a few days but I couldn't find a correlation in the time between incidents, also no obvious events (like draft nodes/unpublish content from the view etc) or traffic (look for weird query params etc) seems to trigger the view to go empty.

Duration Between Incidents:
Aug 18, 06:43 → Aug 18, 11:46: ~5 hours
Aug 18, 11:46 → Aug 19, 15:12: ~27.5 hours
Aug 19, 15:12 → Aug 20, 14:30: ~23.5 hours

So I think I found two issues which this MR attempts to solve, the per user role cache contexts, and also some not great empty check logic. And I got the if !Element::isEmpty($content) from how some core modules such as core/modules/block/src/BlockViewBuilder.php

I validated some of this locally after testing.
- Anonymous users get cache entries with [user.permissions]=a1ad909ca5c5...
- Admin users get cache entries with [user.permissions]=is-admin
- Each user role gets its own properly isolated cache bucket
- No more cache collision between user types

Before making this issue I reviewed past issues and found some similar reported events, all of which seems could not be re-produced. (see related)

nicholass → created an issue.

So for other who stumble on this issue it seem the problem is the default "Stream" behavior, if you disable the stream the chatbot almost never does this anymore. Bug lies I think in the decoder sometimes the action comes in too late.

Looking at the code in PromptJsonDecoder.php lines 55-75, it only tests the first 10 chunks for JSON markers like {, [, etc. If those markers aren't in the first few chunks (because the AI started with conversational text), it assumes it's not JSON.

Simple Solution: Turn of streaming if your primarily using it for RAG.

Here is another longer term screenshot in the consumption reduction from our prod we have been running this patch for about a month.

@generalredneck - Sure thing must have been a copy paste mistake, that module has already merged that change. I've already had this patch on my prod server it helped consumption like me screenshot shows and reduced consumption.

nicholass → created an issue.

Sorry to report but even with this patch and my other I still can't bulk process all the nodes, it worked intermittently locally but almost never on our dev server. I am just going to remove this module its been too problematic for our site. Hopefully you can get it working one day. I think it has something to do with all the nested language loops in the batch.

AI tools thought the following could be the issue, but after hours of attempting to patch I gave up. But here are some breadcrumbs for the next person.

After reviewing the code, I've identified several critical memory and performance issues:

Major Issues:
Router Lookup Explosion: views_url_alias_get_path_entity_type() is called for every language variant, even when the path is identical (e.g., /node/123). This is extremely expensive.

Repeated Entity Loading: The same entity is loaded multiple times across different languages without caching.

Individual Database Operations: Each save operation performs separate DELETE and INSERT queries instead of batching.

Memory Accumulation: Entity cache pollution from loading multiple translations without cleanup.

Can the typehint be added back? Removing it makes my other patch fail to apply https://www.drupal.org/project/views_url_alias/issues/3491389 🐛 Some path alias crash the creation of the views_url_alias table Active

MR33 fixes the error that prevents the database update from working correctly, while maintains the original module intent of working with content entities but adds the needed error handling for sites with webform enitities.

Can't update to dev version because of this error.

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

Looks like the issue i have is better to post to https://www.drupal.org/project/views_url_alias/issues/3491389 🐛 Some path alias crash the creation of the views_url_alias table Active

Great I can help if you get a branch going, I was going to maybe take a stab at it as well.

I too think this is how the module should have been setup, All the reports be editable and installed from config when first installing the module, and maybe a library of "Pre-made" prompts people can choose from so those default ones can be improved over time.

nicholass → created an issue.

Also fixed my "The AI CKEditor dialog form is causing a container serialization error because the plugin instances with service dependencies are being stored in the form cache, and when Drupal tries to serialize the form for caching" issue when attempting to create a custom AI Automator, had similar ajax error console in devtools, but no images involved like original poster.

Also had to disable the "Linkit profile" for Ckeditors after updating core 10.5 due to the error "Cannot convert undefined or null to object" in CKEditor 5 caused by a bug in the Linkit module version 6.1.6. Specifically, in the JavaScript file index.js at line 122, the code attempts to call Object.assign(args[2], values) where args[2] can be undefined or null. This occurs when the CKEditor 5 link command is executed with fewer than 3 arguments, but the code assumes the third argument (index 2) will always be an object.

When title is empty and clicking insert

Relating to another module that had a similar issue and also was fixed.

This change has greatly reduced the time consumption of this module

Just to report back that yes this patch did indeed help quite a bit with module usage after deployment. Thanks!

I could try it if you have a guide for "Field Widget Action + AI Automators" but honestly after testing the filename token seems to be all the context I need, its good enough to get us and our content editors can adjust from there. Plus teaches them to name their images better which helps content maintenance.

I experimented a lot trying to get AI to use the filename, but only luck I had was by adding a token so that I can specifically include it in our prompt template. And for the images I tested this seemed to have a very beneficial effect, so this change just adds a filename token.

Along with IMPORTANT: This image has the filename "{{ filename }}" - use keywords from this filename as strong hints about the image content and incorporate relevant context into your description. it has greatly improved our images alt text. So I feel like this shouldn't be too much of a request to add this token.

I added an image to help test this feature request. All I get back is variations like "Single-story beige house with garage, front lawn, and trees in the background."

Also tried some prompt engineering but I just don't think it has access to the filename?
11. If the filename of the image is available you can use it for hints for context as to what is shown in that image and work those words into the description.

I wonder if the file name could also help situations like #3493133

nicholass → created an issue.

MR121 looks good to me, no errors our Cypress e2e testing suite dropped from 34:41 to 34:02 so I think this hopefully have a performance impact, but I will only truly know really until its on a prod environment with much more sustained traffic to really know.

Thank you @trackleft2

nicholass → created an issue.

Awe ok I see you working on a version of this for 4.0.24, that explains why I could use composer to test the patch on our site, so I will pause my MR121 in favor of your branch. I did switch to the dev branch and was able to test MR121 and it seemed fine to me.

Glad your looking into it thank you.

I think these changes should have perf improvement since it bails early for anon users and don't waste time with config calls. But I won't really know until it released to prod, but I don't see it breaking anything locally.

nicholass → created an issue.

@rachel_norfolk Is this a duplicate of 3433027? Because that one says fixed, but when I tested the 3.x-dev I still got an error during the database updates and the primary keys on the tables could not be fixed due to that error. That's why I created MR31

merge request !31 - Allowed me to run the Dev branch database update successfully.

----------------- ----------- --------------- ------------------------------------------------------------------------------------------
Module Update ID Type Description
----------------- ----------- --------------- ------------------------------------------------------------------------------------------
views_url_alias 10301 hook_update_n 10301 - Implements hook_update_N(). Install indexes, add new column, add primary key.
views_url_alias 10302 hook_update_n 10302 - Implements hook_update_N(). Reinstall the schema, rebuild views_url_alias table.
----------------- ----------- --------------- ------------------------------------------------------------------------------------------

// Do you wish to run the specified pending updates?: yes.

> [notice] Update started: views_url_alias_update_10301
> [notice] Update completed: views_url_alias_update_10301
> [notice] Update started: views_url_alias_update_10302
> [notice] Update completed: views_url_alias_update_10302
[success] Finished performing updates.

So I tried out the dev version but get an error with the Databaseupdate @ruslan_piskarov

Module Update ID Type Description
----------------- ----------- --------------- ------------------------------------------------------------------------------------------
views_url_alias 10301 hook_update_n 10301 - Implements hook_update_N(). Install indexes, add new column, add primary key.
views_url_alias 10302 hook_update_n 10302 - Implements hook_update_N(). Reinstall the schema, rebuild views_url_alias table.
----------------- ----------- --------------- ------------------------------------------------------------------------------------------

// Do you wish to run the specified pending updates?: yes.

> [notice] Update started: views_url_alias_update_10301
> [error] views_url_alias_get_path_entity_type(): Return value must be of type ?Drupal\Core\Entity\ContentEntityInterface, Drupal\webform\Entity\Webform returned
> [error] Update failed: views_url_alias_update_10301
[error] Update aborted by: views_url_alias_update_10301
[error] Finished performing updates.

Failed to run drush updb -y: exit status 1

I also got an error related to the primary keys issue, sovled by clearing cache. When adding a content type I got

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'views_url_alias.PRIMARY': INSERT INTO "views_url_alias"

Which I think is fixed by having good primary keys

Why can't we just do something simpler like this?

  public function getAliasByPath($path, $langcode = NULL) {
    // Normalize the path: handle empty/null paths and ensure proper formatting.
    if (empty($path) || $path === '') {
      $path = '/';
    }

    // Ensure the path starts with a slash. If it doesn't, prepend one.
    if (!str_starts_with($path, '/')) {
      $path = '/' . $path;
    }

That seems to fix things that I tested from the comments above

• https://www.example.gov//
• /index.php5
• /index.php.
• /index.php.?hTTp://r87.com/n
• /index.phpI-dont-exist
• /index.php.php/some/path

This also occurs if someone just adds an extra / to the homepage, for example https://www.example.gov// which the htaccess route (3043779-htaccess-no-php-danglers) doesn't cover that situation.

And the other patch (3043779-source-path-has-11.x) results in a new error

The website encountered an unexpected error. Try again later.

Error: Call to a member function get() on null in Drupal\path_alias\AliasManager->getAliasByPath() (line 199 of core/modules/path_alias/src/AliasManager.php).
Drupal\protected_pages\EventSubscriber\ProtectedPagesSubscriber->checkProtectedPage(Object, 'kernel.response', Object)

Hi Kevin, yeah its been on my list to see how this module works with the media library and paragraphs. So no there is not a hidden setting, I think I need to probably make some adjustments to have it work with the media library, our site doesn't use media library much but I know others do.

Hi Kevin, one workaround you could do right now is use the views_bulk_operations I imagine to just simply bulk update those nodes you want scanned? I haven't tried that but that should queue them up. But keep in mind the free tier in adobe only allows 500 credits per month.

I have been thinking there should be a UI to manually initiate a scan of file(s) but haven't gotten there yet.

Summary: GitLab CI Functional Test Failures Due to PHP 8.3+ Deprecations
The Problem
GitLab CI pipeline was failing with 5 functional tests throwing fatal errors due to PHP 8.3+ deprecation warnings:

Root Cause Analysis
PHP 8.3+ Breaking Change: PHP 8.3 deprecated calling get_class() without arguments
Drupal Core Issue: The deprecation was triggered by Drupal core code (StatusMessages->getInfo()) - not your module code
CI vs Local Environment:
Local tests passed fine (15/15 tests including 5 functional)
CI environment treated deprecations as fatal errors
GitLab CI Template Behavior: The Drupal CI templates' deprecation handling was interfering with our attempts to ignore these warnings
Solutions Attempted
Custom .deprecation-ignore.txt - Created patterns to ignore the specific get_class() deprecation
"Weak" mode - Tried SYMFONY_DEPRECATIONS_HELPER: "weak" to treat deprecations as warnings
Core's ignore file - Attempted to use Drupal core's existing deprecation ignore patterns
Multiple configuration approaches - Global variables, job-specific variables, before_script exports
Why Nothing Worked
The Drupal CI templates aggressively override project-specific deprecation settings
Even when SYMFONY_DEPRECATIONS_HELPER was set correctly, it wasn't being passed through to the actual PHPUnit execution
The CI environment was treating unavoidable core deprecations as test failures
Final Solution: Disable Functional Tests

Will revisit functional test when I test Drupal 11

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