The attached patch adds the "refresh => wait_for" parameter to the preview document index query to immediately refresh the index after the indexing.
Adding a patch which adds to the MR provided by artis.bajars:
- Support for _type is removed.
- Configuration schema for Elasticsearch Helper Content index plugin is added.
- Validation for front-end app URL is added (must be external).
- Phpdoc variable descriptions are added.
The patch sets the cache max-age to 0 on the preview response.
maijs → created an issue.
vladimiraus → credited maijs → .
Adding a patch that adds the config/schema/toc_filter.schema.yml file.
Given that the "auto" field is a dropdown with a list of string options, the type of the "auto" configuraton option should be "string".
Elasticsearch Helper is designed to be a developers' helper tool, where developer has the full control over the indexing.
For a more user friendly experience, see if Elasticseach Helper Content → module is more suitable. It allows creating indices in UI, selecting specific fields with specific format.
This feature has been added to the ElasticsearchIndexManager, albeit in a bit of a different way.
The authentication settings form has been rewritten, and the described behaviour most likely can not longer be reproduced.
The 8.x-6.x branch of Elasticsearch Helper should work with Elasticsearch version 6.
Given that Elasticsearch 6 is no longer supported, there won't be any updates to the 8.x-6.x branch.
The issue is not clear, and is marked as won't fix.
Each index plugin must implement the getMappingDefinition() method which returns an instance of MappingDefinition.
The index plugins can be managed with the Elasticsearch Helper Index Management → module.
This has been fixed, and errors are properly caught and logged.
Thanks, Eelke! This fix will be included in the next release.
Here's the follow-up update to the patch in #117.
- The following code is reinstanted back to InlineEntityFormComplex.php file as removal of these caused namespace reference loss for existing code:
use Drupal\Component\Utility\Tags;
use Drupal\Core\Entity\Element\EntityAutocomplete;Adding refactored patch for the 3.x branch (c753ec1).
- The following code is reinstanted back to InlineEntityFormComplex.php file as removal of these caused namespace reference loss for existing code:
use Drupal\Component\Utility\Tags;
use Drupal\Core\Entity\Element\EntityAutocomplete;This issue has been resolved with the 8.0.0 release.
The 8.x-7.0 and 8.0.0 versions are compatible with Drupal 10.
The 8.x-6.x branch is no longer supported.
maijs → created an issue. See original summary → .
Are there any updates on this? The namespaces for elasticsearch_helper_aws, elasticsearch_helper_content and elasticsearch_helper_instant standalone modules are still with double names.
I believe the old revisions are being re-indexed because Drupal changes the author for every revision to strip any reference to the user being removed. It's a side effect of Drupal/ESH cohesion.
It really comes down to Elasticsearch index plugins that do the actual indexing. Ideally, it should only index entities that are published. In that case no revision without a published state would be indexed.
Given the that fact that Elasticsearch Helper doesn't provide any index plugins on its own, I'm marking this as works as designed.
The provided patch mitigates the problem by checking if the entity type has the "bundle" entity key prior to reindexing entities.
@hestenet, while switch for elasticsearch_helper_views took place as expected (see
https://www.drupal.org/project/elasticsearch_helper_views/releases/8.x-dev →
), the other modules are still double-named, even after adding a development release.
See https://www.drupal.org/project/elasticsearch_helper_content/releases/8.x... → , for example.
maijs → created an issue.
Event listeners now can access and modify the index_definition object when an index is created. This allows custom modules to modify the index settings and the mapping.
See an example in the elasticsearch_helper_example module - https://git.drupalcode.org/project/elasticsearch_helper/-/blob/8.x/examp...
The object oriented approach to index mapping has been introduced in version 7, and since then the best way to alter the data prior to an Elasticsearch operation was to use an event listener.
The patch attached allows event listeners to receive the index name and the index definition instance (incl. the mapping definition), and alter the existing mapping or add a new field.
The patch also includes an example event listener included in the elasticsearch_helper_example module.
Thanks! Due to the frequent abuse of contribution credit harvesting on help hook related issues, I'm skipping the credit attribution on drupal.org.
I've cleaned-up the change created by Jose Jiménez in https://git.drupalcode.org/project/varnish_purge/-/merge_requests/8.
The summary of the overall change in MR!10:
1. The purging of entity images is queued instead of performing the purging requests from within the entity_update hook.
2. The purging logic is moved from entity_update hook into purge module plugins.
The summary of the interdiff of MR!8 and MR!10 is the following:
1. The configuration form moved to the varnish_image queuer plugin.
2. The patch file which was commited in MR!8 is removed.
Sorry for not providing enough context for why this is important. In a project there's a requirement to lock the webform when the mailing of the submission values resulted with a failure. After the webform administrator makes sure that the webform is properly sent/resent via email to the relevant parties (according to the email mailer), the webform is manually unlocked, and the webform is then processed according to purging policies.
I have updated the text of the issue for clarity.
As I mentioned before, the \Drupal\Core\Mail\MailManagerInterface::mail() PhpDoc states that it's the result element that contains the result of the mailing. The send element that the sendMessage() method returns is the intent to send or not to send the email, and not the result itself.
Interestingly enough the \Drupal\webform\Plugin\WebformHandlerMessageInterface::sendMessage() PhpDoc doesn't state any return value, yet it returns the $result['send'] (intent) value.
My suggestion is to make the return of the sendMessage() method more meaningful, so that overriding classes could act on what happens within the sendMessage() method without copying and pasting the whole method's code just to return the success or the failure of the mailing.
The elasticsearch_helper_index_management_update_8001() function may not be required on the new installs, but I don't see a good reason to remove it altogether.