🇺🇸United States @j-barnes

Thanks for testing!

We’re experiencing this same issue with larger file uploads. When using the widget, files are uploaded directly to S3 client-side. However, the fileInput element still retains the selected file. This means when the form is later submitted via FormData, the file is included again in the request body — even though it was already uploaded — which can cause server-side errors such as exceeding post_max_size.

I think the simple solution is just to clear the fileInput value so that FormData doesn't include the file.

j-barnes → made their first commit to this issue’s fork.

j-barnes → created an issue.

It looks like the project is listed under community projects which is has some limitations.

In the meantime, I’ve been using the patch below to purge the items once it reaches a specified size:

https://www.drupal.org/project/admin_audit_trail/issues/3197592 ✨ Add settings to toggle between expanded/collapsed filters. And set an option to limit database table size Needs work

Updated the latest patch to include a small change to allow for patterns similar to how config ignore works. We encountered a use case where enabling client-side validation for all webform submissions was necessary. However, manually adding hundreds of form IDs was impractical.

Example:

webform_submission_name_change_test_form
webform_submission_*

@nicholass – Thanks for the patch! It's working great. I've rebased this and made a few minor updates, including dependency injection and some coding standard improvements. I'm also opening a merge request to get more eyes on it. Appreciate your work on this!

j-barnes → made their first commit to this issue’s fork.

Also looking at including this in our project if a release is created, thanks!

Awesome, our team was actually just asking about this functionality. Seems to be working great. Thanks for the contrib!

j-barnes → made their first commit to this issue’s fork.

j-barnes → created an issue.

I've added a new token access test based off the webform populate test. Let me know if you'd like any changes or if you'd prefer some kind of base class added. This should at least get us headed in the right direction.

@Joe - Thanks for the contribution, this is working great for our team. Created the MR for this so we can hopefully get it merged soon.

Seems to be related to and fixed in: https://www.drupal.org/project/drupal/issues/2896169 🐛 Details elements have incorrect aria-describedby attributes Needs work

That makes sense to me, I'll do that going forward. I fixed the one issue, but I think the others may be unrelated. See below:

------ -------------------------------------------------------- 
Line   tests/src/Functional/HandlePdfControllerTest.php        
------ -------------------------------------------------------- 
20     @coversDefaultClass references an invalid class         
       \Drupal\fillpdf\Controller\HandlePdfController          
                                                               
       Also covers \Drupal\fillpdf\Plugin\FillPdfActionPlugin  
       and \Drupal\fillpdf\OutputHandler..                     
       🪪  phpunit.coversClass                                 
------ -------------------------------------------------------- 
[ERROR] Found 1 error 

FILE: ...3/web/modules/custom/fillpdf-3460893/tests/src/Traits/TestFillPdfTrait.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
 112 | WARNING | [x] Empty PHP statement detected: superfluous semicolon.
     |         |     (Generic.CodeAnalysis.EmptyPHPStatement.SemicolonWithoutCodeDetected)
--------------------------------------------------------------------------------

Thanks for the feature, this is working great for us! I went ahead and updated / refactored this for the new 5.2.x-dev branch.

j-barnes → changed the visibility of the branch 3460893-webform-fillpdf to hidden.

We are currently experiencing the same issue on the latest Webform 6.3.x-dev utilizing the name element when dealing with multiple values.

Below is the outputted value using a dump on the submission view, so the input does exist.

After digging a bit, you can see the below value that gets passed for rendering. The template item-list expects to receive a flat structure, so the item is never rendered. The table view uses a different composite rendering function, is unaffected by this issue.

A simple fix to get us started is to add modifications to: docroot/modules/contrib/webform/src/Plugin/WebformElementBase.php

if ($item) {
    $items[] = is_array($item) ? reset($item) : $item;
}

This adjustment flattens the item, allowing it to render correctly. However, further review is needed to ensure there are no unintended side effects from this change.

Attaching patch with update hook that we used to fix the issue.

Thanks for the patch, working great for us. Re-rolling against the latest changes.

j-barnes → made their first commit to this issue’s fork.

We ran into this issue when upgrading from 2.2.2 to 3.3.3. We realized that we had a drush cr before our drush updatedb.

Following the correct drush deploy sequence fixed our issue.

drush updatedb --no-cache-clear
drush cache:rebuild
drush config:import
drush cache:rebuild
drush deploy:hook

j-barnes → created an issue.

j-barnes → created an issue.

This is still an issue in the latest, the above fixes the problem for us.

Unassigning myself for now due to higher priority tickets, will revisit soon.

Updated, thanks!

j-barnes → created an issue.

j-barnes → created an issue.

@Bradley-B - Removing the && ($conjunction == 'AND') worked great for our use case. We use "Contains Any" for our full text search, which does not appear to work correctly in conjunction with "match_entire_string". Thanks!

@asigrist - Thanks for the breakdown. We are facing the same issues on some of our forms that leverage "Acrobat's Extended" version. Ghostscript actually regenerates the PDF file, but also flattens it -- which results fillable forms being in a printed state.

Originally, we leveraged ExifTool with a PHP wrapper. This allowed us to not have to regenerate the entire PDF, but rather only modify the metadata. At the time, the library was not being maintained (so we switched over to Ghostscript) -- but it looks like it is now so it might be a good opportunity make this module a bit more generic and allow multiple providers.

I think we can solve this but implementing the below:

1. Introduce generic providers.
2. Add back Exiftool with ability to toggle between providers.

j-barnes → made their first commit to this issue’s fork.

j-barnes → created an issue.

j-barnes → made their first commit to this issue’s fork.

@jenny.tollerson / @alemadlei - Our team was running into the same issue using the "Views Infinite Scroll" pager in a view with ajax enabled. After the user clicks the "Load More" it jump back up to the top of the page after a minor delay. We have the translate block attached to the top of the page via block layout. Adding this has cured the problem for us, thanks for the patch!

@Defcon0 - I'm running into the same issue where my times went up significantly after enabling the Highlight processor (with Retrieve result data from Solr" and "Retrieve highlighted snippets" enabled).

Query build time   49.77 ms
Query execute time   130.9 ms
View render time   229.75 ms

to

Query build time   53.55 ms
Query execute time   1988.97 ms
View render time   2075.75 ms

After troubleshooting a bit, I noticed that field / excerpt were not available when the field was not explicitly added to the view. After adding my rendered_html field to the view (hidden), my times were near instant again. (Originally I just had Search: Excerpt and would select my search fields in Search: Fulltext search)

With render html field added to the view:

Without render html field:

Added a simple option to allow for disabling the post process query.

j-barnes → created an issue.

Added a couple minor tweaks, but tested and this is working great! Going to have some internal team members QA this and we should be good to go to merge. Thanks again for the contribution!

@mostepaniukvm - What are your thoughts on adding a role field and also incorporating the prompt replacement {input} similar to how the other augmentor behaves.

https://git.drupalcode.org/project/augmentor_chatgpt/-/blob/1.0.x/src/Pl...

  if ($role == 'user') {
    $content = str_replace('{input}', '"' . addslashes($input) . '"', $this->configuration['prompt']);
  }
}

@mostepaniukvm - Looks great, going to give this a try. Thanks for the MR.

j-barnes → created an issue.

j-barnes → created an issue.

j-barnes → created an issue.

Yep that is the current solution we are leveraging with the serialization / unserialization - takes a few more additional steps, but it does the trick!

Gave it another go, but looks like it works only on the page attachment / page processing and does not persist on the field.

Here is the full example:

Looks like it only triggers an alter event on update if there is already a value, so in that case I put a random description.

Simple alter tag event, we set the new tag.

This updates correctly on the page load / source code with the new value, but it does not persist in the actual field. So in order to leverage this our AI would need to be called on each page hit, which would be a lot.

That makes sense, I was afraid that might create an endless loop - but it looks like metatag doesn't resave the entity after setting the tag. However this means that it also does not persist the data? It looks like this may be a better use case during the page processing. Not a huge deal though, we can still achieve the result with a presave / serialize action. Thanks!

j-barnes → created an issue.

j-barnes → created an issue.

@eleonel - Tried giving this patch a go, but I am getting the below error in regards to a null "allowed_fields" variable.

Steps to reproduce:

1. Add a new Augmentor Field to a content type.
2. Go to manage form display and see error.

TypeError: Drupal\augmentor\AugmentorManager::isAugmentorValidTarget(): Argument #2 ($allowed_fields) must be of type array, null given, called in /var/www/html/docroot/modules/contrib/augmentor/src/Plugin/Field/FieldWidget/AugmentorBaseWidget.php on line 194 in Drupal\augmentor\AugmentorManager->isAugmentorValidTarget() (line 198 of modules/contrib/augmentor/src/AugmentorManager.php).

Drupal\augmentor\Plugin\Field\FieldWidget\AugmentorBaseWidget->settingsForm(Array, Object) (Line: 450)
Drupal\field_ui\Form\EntityDisplayFormBase->buildFieldRow(Object, Array, Object) (Line: 40)
Drupal\field_ui\Form\EntityFormDisplayEditForm->buildFieldRow(Object, Array, Object) (Line: 213)
Drupal\field_ui\Form\EntityDisplayFormBase->form(Array, Object) (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)

j-barnes → created an issue.

j-barnes → created an issue.

@SiliconValet - thanks for the patch! I am getting the below error and I assuming this is because the getModels() function doesn't exist because the model is explicitly declared when creating the client, but most of the sub modules check for that function?

OpenAI\Exceptions\ErrorException: Resource not found in OpenAI\Transporters\HttpTransporter->throwIfJsonError() (line 131 of /var/www/html/vendor/openai-php/client/src/Transporters/HttpTransporter.php).

OpenAI\Transporters\HttpTransporter->requestObject(Object) (Line: 28)
OpenAI\Resources\Models->list() (Line: 86)
Drupal\openai\OpenAIApi->getModels() (Line: 130)