yannickoo → credited aaron.ferris → .
Odd, same setup here and the form loads as I would expect
You may need to use minimum-stability: dev
in your composer.json
However, it installs fine for me on a fresh D11 project with "minimum-stability": "stable"
.
x@Mac drupal-11 % ddev composer require 'drupal/eca:2.1.x-dev@dev'
./composer.json has been updated
Running composer update drupal/eca
Loading composer repositories with package information
Updating dependencies
Lock file operations: 4 installs, 0 updates, 0 removals
- Locking dragonmantank/cron-expression (v3.4.0)
- Locking drupal/eca (dev-2.1.x 3b3b975)
- Locking mtownsend/xml-to-array (2.0.0)
- Locking webmozart/assert (1.11.0)
Raised an MR for this, however, and I could be wrong, but I think this will only be compatible with D10+
aaron.ferris → made their first commit to this issue’s fork.
Thanks for this patch, I just came across this issue on one of my projects. Ive raised an MR into 2.x.
aaron.ferris → made their first commit to this issue’s fork.
Testing steps
1. Enable the module
2. Export synonyms, via cron or drush
Expected: The renaming of the function should not have impacted anything, synonyms should still be exported.
Testing steps
1. Enable the module
2. Configure the file directory for this module
3. Export synonyms
Expected: The configured folder should contain the exported synonyms
1. Reconfigure by removing the custom folder location
Expected: Synonyms should be exported to public://synonyms
Testing steps
1. Enable this module
2. Enable jsonapi
3. Assign the new permission view search api synonyms to relevant roles
4. Go to /jsonapi/search_api_synonym/search_api_synonym
Expected: if the user has the permission, they should be able to view the synonyms as json
1. Remove the permission from the same roles
2. Go to /jsonapi/search_api_synonym/search_api_synonym
Expected: The synonyms should not be viewable (we should see the same response from the original ticket description).
Thanks, tested this, the form no longer submits without the required file. This should suffice. Will merge once the pipeline completes.
Had a look at this, not sure why the file field is set to be optional - perhaps this form had other methods of importing synonyms in a previous version, but looking at the form from 3.x it looks to be required.
aaron.ferris → created an issue.
Thanks @jonathandealmeida - pushed a couple of minor changes. Will merge once the pipeline completes
Thanks all! Merged.
Seems this is missing this from 2.x - I wonder if one of the recent phpcs ticket changes stripped it
ImportPluginBase
/**
* {@inheritdoc}
*/
public function submitConfigurationForm(array &$form, FormStateInterface $form_state) {
parent::submitConfigurationForm($form, $form_state);
}
Apologies I missed the conflicts message, thanks @lavanyatalwar for resolving.
Postponing for Zoocha contrib day.
aaron.ferris → created an issue. See original summary → .
Postponing for Zoocha contribution day.
aaron.ferris → created an issue.
My votes are:
- Marine Gandy (Mupsi)
- Will Huggins (zoocha-will)
All the best all!
Not really sure what the intention is re: 1.x/2.x so raised an MR against both.
aaron.ferris → made their first commit to this issue’s fork.
aaron.ferris → made their first commit to this issue’s fork.
Thanks @nexusnovaz - there are some conflicts that need to be resolved here.
aaron.ferris → made their first commit to this issue’s fork.
Thanks for the MR and patch, ive pulled this change down and can see that the change fires Drupal.jstimer.timer_loop as expected, im not seeing anything untoward as far as regressions are concerned. Merged.
aaron.ferris → made their first commit to this issue’s fork.
aaron.ferris → changed the visibility of the branch 2.0.x to hidden.
aaron.ferris → changed the visibility of the branch 3511224-fix-cspell-issues to hidden.
aaron.ferris → made their first commit to this issue’s fork.
Thanks both, merged.
Isn't Country a required field, as in, the address itself can't be added without it?
Could you please provide reproduction steps in getting the country to be empty? Migrated values perhaps?
Not that this change isn't the right way, im just wondering if this being empty could have consequences elsewhere.
Added a permission/entity view hook for this.
Example jsonapi response with an anonymous user, with access to view
{"jsonapi":{"version":"1.0","meta":{"links":{"self":{"href":"http:\/\/jsonapi.org\/format\/1.0\/"}}}},"data":[{"type":"search_api_synonym--search_api_synonym","id":"abb09e71-552d-4ad0-bf75-804b0e969469","links":{"self":{"href":"https:\/\/drupal-11.ddev.site\/jsonapi\/search_api_synonym\/search_api_synonym\/abb09e71-552d-4ad0-bf75-804b0e969469"}},"attributes":{"drupal_internal__sid":4,"langcode":"en","search_api_synonym_type":"spelling_error","word":"marmelade","synonyms":"marmalade,mermelad,marmellade","status":true,"created":"2025-04-27T13:01:40+00:00","changed":"2025-04-27T13:01:40+00:00","field_asddsadasd":null},"relationships":{"uid":{"data":{"type":"user--user","id":"1f83400a-0892-4ed0-99b3-1379d9c831b3","meta":{"drupal_internal__target_id":1}},"links":{"related":{"href":"https:\/\/drupal-11.ddev.site\/jsonapi\/search_api_synonym\/search_api_synonym\/abb09e71-552d-4ad0-bf75-804b0e969469\/uid"},"self":{"href":"https:\/\/drupal-11.ddev.site\/jsonapi\/search_api_synonym\/search_api_synonym\/abb09e71-552d-4ad0-bf75-804b0e969469\/relationships\/uid"}}}}}],"links":{"self":{"href":"https:\/\/drupal-11.ddev.site\/jsonapi\/search_api_synonym\/search_api_synonym"}}}
Tested the change, looks fine. Ill leave this as RTBC for a couple of days to see if there are any arguments against merging.
Code change looks fine, I don't see any inherent reason not to expose fields, just wondering what the use case could be, custom export/import plugins?
Search API solr, at least as far as I can tell, has moved away from managed resources. Indeed, if you try and use ManagedSynonyms the config export will strip the field. This is still technically feasible, with a custom export plugin, but im not convinced we should be incorporating this into the module given the standardised approach of search_api_solr (using a file).
The phpcs pipeline is passing on 3.x, 2.x is considered legacy at this point.
8.x is unsupported. Please create a new ticket for 2.x/3.x.
Agreed this is odd.
MR raised
#
# Synonyms file for Apache Solr generated by Search API Synonym.
# See file https://www.drupal.org/project/search_api_synonym.
#
marmalade,mermelad,marmellade => marmelade
search => replace
Agreed with this, I don't think we need to change the synonym case but the spelling error does need a switch I believe.
Ive reviewed these changes, they're not applicable anymore as far as I can tell.
Made an initial start on this, we will need to compile the synonyms to add to the files post config creation.
Ive decided to take a slightly different approach to this, by adding another option in the interval select.
This should give the best of both worlds. We now have
1. Never - self explanatory
2. List of intervals - the way the module has historically worked
3. Bypass - which leaves the cron configuration open, but will ignore any time based interval, so that it can be used with Ultimate Cron and the likes
Feedback/testing welcome.
aaron.ferris → changed the visibility of the branch 3471724-remove-cron-frequency to hidden.