🇭🇷Croatia @devad

Thanks for update @tjtj. Just a note for others who may experience the same issue.

If you are using Composer to manage your project packages you have to UNINSTALL Ludwig.

Are you using Composer or Ludwig to manage your packages... or both?

Yes. The synonyms can be stored in entity reference fields as well. So, you can declare your taxonomy related entity reference field as the source of synonyms for your desired entity.

Re: #17

You are right @dqd. It is the upgrade issue here.

The error messages which appeared in my tests described in my comments #14 and #16 are due to known issue described here: #1959170: Applying dependency on entity reference/autocomplete field does not work → . Sorry for noise.

What does that has to do with this issue which is about issues of already existing dependencies in an Drupal core update between 9.5 to 10?

As much as I have tested this issue is for general 4.x branch compatibility with D10. Not for D9 to D10 upgraders only.

I cannot reproduce what you tested.

I tested it again with 4.x-dev and the issue remains the same. Did you try to create the described dependency and edit it afterwards? No error message for you?

Re: #13

Ok. I'll try to help. Let's do a simple reproduce.

Clean standard Drupal 10.2.4 + Conditional Fields 4.0.0-alpha5 installation.

Visit /admin/structure/taxonomy/manage/tags/overview and create few Tag terms: tag1, tag2, tag3...

Visit: /admin/structure/conditional_fields/node/article and add new dependency:

- Target field: Body (body)
- Control field: Tags (field_tags)
- Keep the rest default and proceed with "Add Dependency" button.

At the next screen:

- Condition: Value
- Values input mode: Insert value from widget
- Inside the Tags field select: tag1
- Keep everything else default and save settings

Clear caches just in case...

Go to Add new Article form (/node/add/article). The "Body" field is hidden by default and it should become visible if "tag1" Tag term is selected. But it does not work. When "tag1" term is selected inside the "Tags" field - the "Body" field is not becoming visible.

It may help for debug... additionally, a few JS errors are visible inside my Chrome browser's console:

Uncaught TypeError: reference.indexOf is not a function

It may help also... the attempt to edit newly created dependancy fails with error message:

The website encountered an unexpected error. Try again later.

InvalidArgumentException: Value is not a valid entity. in Drupal\Core\Entity\Plugin\DataType\EntityReference->setValue() (line 106 of core/lib/Drupal/Core/Entity/Plugin/DataType/EntityReference.php).
Drupal\Core\Field\FieldItemBase->writePropertyValue('entity', Array) (Line: 293)
Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem->onChange('target_id', ) (Line: 239)
Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem->setValue(Array, ) (Line: 208)
Drupal\Core\TypedData\TypedDataManager->getPropertyInstance(Object, 0, Array) (Line: 91)
Drupal\Core\Field\FieldTypePluginManager->createFieldItem(Object, 0, Array) (Line: 41)
Drupal\Core\Field\FieldItemList->createItem(0, Array) (Line: 69)
Drupal\Core\TypedData\Plugin\DataType\ItemList->setValue(Array, 1) (Line: 107)
Drupal\Core\Field\FieldItemList->setValue(Array, 1) (Line: 657)
Drupal\Core\Entity\ContentEntityBase->set('field_tags', Array) (Line: 566)
Drupal\conditional_fields\Form\ConditionalFieldEditForm->getDummyField('node', 'article', Array, Object, Array) (Line: 171)
Drupal\conditional_fields\Form\ConditionalFieldEditForm->buildForm(Array, Object, 'node', 'article', 'body', 'a6457cfb-fa78-460e-abe4-b725dd0aacf8')
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('conditional_field_edit_form', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

RE: #79

The Ludwig integration is added recently ✨ reCAPTCHA - Ludwig integration Fixed , so the latest 8.x-3.x-dev can be installed with Ludwig as well. Of course, the Composer is highly recommended whenever possible.

I believe this issue can be closed as outdated. If you have a proper Composer installation or the proper Ludwig + reCAPTHA 8.x-3.x-dev installation and you still experience this issue please feel free to reopen.

Tested. Everything works fine now. Closing as outdated. Thanks for reminder @rachel_norfolk.

I tried to reproduce. But, this time the build was successful.

Thanks for reply @rachel_norfolk. Closing...

Just a reminder re:#6:

TASK: @nonom Please, revert the 3.x branch Ludwig change you made recently.

D10.2.x patch fix.

D10.2.x reroll.

The 3.x branch Ludwig integration does not need fixing. It was fixed already before v3.0.6 is released:

📌 Ludwig integration needs an update Fixed

@nonom Please, revert the 3.x branch Ludwig change you made recently.

Commit to 4.x is ok.

Thank you so much @fgm for your elaborated reply.

I have a rather small site, so switching back to db cache makes a lot of sense.

I'll close this issue as "Cannot reproduce", and maybe someone else will open it again in the future if he/she experience the same issue.

Thanks again! Have a nice holydays!

BTW... one more question.

I couldn't find any information regarding core "Internal Page Cache" and "Internal Dynamic Page Cache" modules when using Memcache.

Should I uninstall this two core modules or should they stay installed? Or it doesn't matter?

Thanks for reply @fgm.

It's a shared sever with cPanel.

These screenshots may help:

- cPanel PHP extensions screenshot
- Status page screenshot
- phpinfo() screenshot
- Memcache statistics (turned on by Memcache admin module) screenshot

devad → created an issue.

devad → created an issue.

Ludwig patch is here.

the 'v' library version prefix is not needed any more. Removed.

The "mobiledetect/mobiledetectlib" library has one new dependency. The "psr/simple-cache" library. It's added to the ludwig.json file

Both libraries are PSR-4 autoload type, so the mobile_detect.module Ludwig integration code snippet is not needed any more.

This patch should do the job nicely.

A request: @nonom Please enable 3.0.x and 4.0.x branches for automated tests.

devad → created an issue.

devad → created an issue.

devad → created an issue.

Maybe it is a bit too late to radically change the concept here but I'll ask nevertheless...

Is it possible to have here two different sets of radios which are shown/hidden by JavaScript?

One set available if the "Required" checkbox is unchecked and the other set of radios available when the "Required" checkbox is checked. As suggested in comment #239.

That would give us enough flexibility for all options we need both currently and in the future.

Note: The "Synonyms UI" submodule is canceled and merged back to the main "Synonyms" module before v2.0.0 is released... due to the WSOD problem described here:

#3216532: WSOD when config_translation (being) enabled →

Note: The "Synonyms UI" submodule is canceled and merged back to the main "Synonyms" module before v2.0.0 is released... due to the WSOD problem described here:

#3216532: WSOD when config_translation (being) enabled →

Additionally... it would be nice if we can make here the "Limit list to select items" option to work nicely with "Is not one of" operator as well... which is not the case currently... but of course, it can be done in the separate issue as well.

This bug (which has evolved into feature) is still around although Views joined the Drupal core many years ago.

Let's assign the "Bug smash initiative" to this issue and see if the Bug smash initiative team has will to deal with it.

It would be great to have Views cleaned up from this ugly 15 years old bug before D11 is released. :)

I am willing to help with manual tests and feedbacks as much as I can.

If you have the Ludwig module already installed, but somehow the library is still not present, the error message is this instead:

Feeds requires the library "laminas/laminas-feed". It can be downloaded by the Ludwig module, which you appear to have installed. Go to Packages list to install the missing libraries.

And "Packages list" links to /admin/reports/packages.

I'll consult @devad (maintainer of the Ludwig module) if this instruction is correct. I did try to install the Ludwig module first and then Feeds afterwards and the library was still missing. But when I went to /admin/reports/packages, the library got downloaded and installed. And then I was able to install Feeds successfully.

Yes. This is all correct Ludwig instructions. Thanks.

MegaChriz → credited devad → .

Glad this helped.

yes, clearing caches worked in fact..

Ludwig has a cache clean embedded into it's code... but it can cache clean only the cache at the site where you have visited the Ludwig > Packages page. At all other sites you need to clean caches manually.

The same drill with cache clean (at all your sites) you will need to go through after updating the symfony_mailer (or any other Ludwig-managed module) next time.

Also... at your multisite configuration... do you have a multiple modules/symfony_mailer folders or only one for all sites?

Did you try this suggestion?

You can try to clear caches at all your sites after visiting Ludwig Packages page... just in case that's the problem in your case.

I don't have any experience with multisite configs,

so where is the difference?

You can try to clear caches at all your sites after visiting Ludwig Packages page... just in case that's the problem in your case.

My log record. Screenshot attached.

I tested.

I get the same error if I try to install Drupal Symfony Mailer module BEFORE all packages are downloaded by Ludwig.

After all packages are reported as downloaded by Ludwig the Drupal Symfony Mailer module installation goes smoothly for me. No more WSOD or errors in logs.

Hi Jochen.

Please send a bit more data about your config.

- Your Ludwig version
- Drupal core version
- php version

devad → created an issue.

For full set of use case options I suppose we should have here:

Case a - when the "Required" field checkbox is not checked

1a. End date is required when the start date is provided (default behavior currently - selected as default for BC reasons)
2a. End date is optional when the start date is provided
(3a.) End date can be provided even if the start date is not provided

Case b - when the "Required" field checkbox is checked

1b. Both start date AND end date are required (default behavior currently - selected as default for BC reasons)
2b. Start date is required only
(3b.) End date is required only
(4b.) Start date OR end date is required

The radio options 3a, 3b and 4b are postponed for later addition. The follow-up issue is here: ✨ Allow start date to be optional Active

Note: English is not my native language, so the better wording is welcome of course.

For full set of use case options I suppose we should have 4 radio options available here:

o Start date AND end date are required
o Start date OR end date is required
o Start date is required only
o End date is required only

The description should be conditional, like "Whether an end date must be provided *if* a start date is given".

+1 for this suggestion.

This description is clear and easy to understand IMHO.

I thing I need to tackle the composer hurdle. I've been doing the old way for so long that I'm a little intimidated by setting it up.

https://www.drupal.org/docs/contributed-modules/ludwig/migration-from-ludwig-to-composer-instructions →

I really like the Ludwig idea, but I think they want to discontinue it.

Ludwig will be around until a new similar official UI tool is completed. 💬 Retire Ludwig? Postponed

bluegeek9 → credited devad → .

Yes, you have the URLs right. The library names should be kept the same as composer's.

This ludwig.json file should work.

{
    "require": {
        "composer/ca-bundle": {
            "version": "1.3.7",
            "url": "https://github.com/composer/ca-bundle/archive/1.3.7.zip"
    },
        "maxmind/web-service-common-php": {
            "version" : "v0.9.0",
            "url": "https://github.com/maxmind/web-service-common-php/archive/v0.9.0.zip"
    },
        "maxmind-db/reader": {
            "version" : "v1.11.0",
            "url": "https://github.com/maxmind/MaxMind-DB-Reader-php/archive/v1.11.0.zip"
    },
        "geoip2/geoip2": {
            "version" : "v2.13.0",
            "url": "https://github.com/maxmind/GeoIP2-php/archive/v2.13.0.zip"

        }
    }
}

Since you said you are using Ludwig... did you created manually the ludwig.json file inside your modules/visitors folder?

Duplicate of related issue. Committed to .dev already.

I have created and pushed a new Synonyms release today for D10 users convenience reasons.

Just a note.

The v1.8.5 of the library requires PHP8:

    "require": {
        "php": "^8.0"
    }

If we upgrade Ludwig library to v1.8.5 it will not be usable for users with Drupal9 + PHP7.4 configuration.

But Drupal 9 is EOL few days ago, so I suppose such an update is ok.

The 2.x-dev version → has Ludwig integration updated already. See:

https://git.drupalcode.org/project/mailchimp/-/commit/91497012bfa8af86ce...

Note: The /refs/tags part of the URL is not needed, so the URL can stay as it is now.

Re: #6

Ludwig is not a proper place to add dependencies to other drupal modules. The .info file is a proper place for that.
See the related issue.

devad → created an issue.

Thanks @ressa and others.

I have changed the first two sentences at the top of the project page to reflect your idea.

Ludwig is retired.

Just a correction... Ludwig is not retired. 💬 Retire Ludwig? Postponed . You can read @bhojanz comment #6.

It is not recommended (Composer is)... but it has not be recommended ever since it was created by Drupal Commerce team 7 years ago. :)

Drupal Commerce supports Ludwig still. However, if you decide not to support it any more within this project - that's ok of course.

Re: #10

If Wordpress can do it fully automatically even in the background I see no reason for Drupal not being able to do the same

It's work in progress. Called Automatic Updates. Not ready for use yet (Alpha release only) . You can take a look at:

https://www.drupal.org/docs/8/update/automatic-updates →
https://www.drupal.org/project/automatic_updates →

Thanks.

Re: #8

Hi @true pal. The second part of your post with a question is off-topic here. To get a proper help it would be better to delete that part from this closed issue and post it as a new issue (support request).

Note for maintainers: It would be nice to have Mobile Detect branch 3.0.x available for automated tests.

Re: #23

If you are using Ludwig to manage your library dependencies (instead of Composer) and you are also using the latest 3.0.x-dev version of Mobile Detect you may need the patch #2 from related issue.

Simple library version upgrade patch.

Note for maintainers: It would be nice to have branch 3.0.x available for automated tests.

devad → created an issue.

Here are some examples which might be useful for issue-reproduce purpose:

Condition which works nicely in my case:
Target controlled by "list type" field with Condition: "Value" and Values input mode: "Any of these values (OR)"

Does not work:
Target controlled by "list type" field with Condition: "Value" and Values input mode: "Insert value from widget"

Does not work:
Target controlled by "entity reference type" field with Condition: "Value" and Values input mode: "Insert value from widget"

Does not work:
Target controlled by "entity reference type" field with Condition: "Value" and Values input mode: "Any of these values (OR)"

Note: All of these conditions worked nicely before I made the D10 upgrade.

This issue still exists in alpha5 as well.

RE #95:

Hi @newswatch. This is not an ideal place for such feature request or further discussion but I will reply here once to help you.

The request for any project's Ludwig integration should be posted at project's issue queue.

The Upgrade Status module dependencies (core dev included) are too complicated for Ludwig integration though.

You can read and follow info "Installation on sites not using composer" at the Upgrade Status project page → .

Thanks all. I tried a .dev committed Facets plugin and it works nicely.

devad → created an issue.

minor

Can you explain why this change is needed? Should we be updating our requirements in composer.json as well?

The best is to update the ludwig.json in the same time the composer.json is updated.

However, the Composer.json file is updated without a ludwig.json update. So, this patch is needed to keep the ludwig.json file in line as well.

I am not familiar with Ludwig and why we need to duplicate requirements there so forgive my ignorance.

This is an explanation from official Why Ludwig? → documentation:

Contributed Drupal modules often require external PHP libraries. Therefore, ever since Drupal 8 is released, preferred tool for Drupal site management is Composer. Ludwig is written as an UI alternative to users who are not friendly with the command line tools yet, or want to avoid Composer usage for other reasons.

Also, you mention downgrading the version, but the patch looks like an upgrade from 9.6.2 to 9.8.0.

From patch #2 to patch #3 interdiff:

- "version" : "9.10.0",
- "url": "https://github.com/thephpleague/csv/archive/9.10.0.zip"
+ "version" : "9.8.0",
+ "url": "https://github.com/thephpleague/csv/archive/9.8.0.zip"

Let's downgrade the thephpleague/csv version back to 9.8.0 to preserve the D10 + PHP8.0 compatibility.

This patch can be used with D8 and D9 sites as well if PHP7.4+ is used.

This patch should do the job.

devad → created an issue.

Re: #3

Here is a quote from the Ludwig project page:

Can I use both Composer and Ludwig in my project?

If you are using Composer to manage your Drupal project you don't need Ludwig, and you shouldn't use it!

If you decide to switch your Drupal project from Ludwig-managed project to Composer-managed project at some point - don't forget to uninstall and remove Ludwig module from it.

Hi

Are you using Composer to manage your site? Or Ludwig? Or both?

Or do i need to clone it to my local first, remove all modules an download again via composer and move everything back?

Yes.

I believe this tutorial can help you. It's created for Ludwig users but it fits your usecase as well:

https://www.drupal.org/docs/contributed-modules/ludwig/migration-from-ludwig-to-composer-instructions →

Re: 10

Without git... the best is to zip your whole local Composer-built site, upload it to server and unzip it there. The same process is needed after some Composer updates are done later. Of course, you need to know how to create/update the database as well.

However, your latest questions are off-topic here now.

Try to find tutorials on how to install Drupal with Composer locally and how to upload website to server. And if you need more support help go to: https://drupal.stackexchange.com/.

So is there any other way like install it on my local pc, using composer and move that modules by copy/paste to server?

Yes, sure. You can build your site locally and upload the whole site to your server. It will work.

Thanks @bojanz. I agree. To retire Ludwig before new UI solution is launched would be harsh to all Drupal users who are not command-line friendly yet.

I have added a note about Ludwig EOL to the project home page with link to this discussion.

Let's postpone this issue until a new UI (which we understand Automatic Updates will eventually be) will be around the corner.

However, feel free to post more comments, or even reopen this issue if needed.

minor

 minor

troubleshooting note added

update

devad → created an issue.

I tested and it works as expected for me. Committed to dev.

Note: The only change I have made before commit is that I have changed the validation message from: 'One of the items entered could not be found.' to: 'At least one of the items entered could not be found.' It is more general.

Thanks @DamienMcKenna.