jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
I don't know what type of Views integration is expected. This module creates entity types and fields that are exposed to views.
Maybe a Views display plugin could expose all the entities listed via JSON-LD.
jrockowitz → created an issue.
nicxvan → credited jrockowitz → .
nicxvan → credited jrockowitz → .
nicxvan → credited jrockowitz → .
Generally, most sites won't want or need Dynamic Yield for admin pages, and there should be a checkbox to enable/disable Dynamic Yield for admin pages. I am not sure we need to support custom exclude rules for the public-facing page.
I created an MR because I think we have to revert this change for now until only Drupal 11 is supported.
Technically, in the Drupal community, we are still supporting PHP 8.2 for Drupal 10.
@see
https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →
I would be open to committing the patch, but I want to nudge you to update to PHP 8.3.
You can try the below patch and see if it fixes the issue.
The problem is PHP 8.2, and I am only testing (and supporting) PHP 8.3+.
Here is a similar issue 🐛 Php 8.2 const definition error Active
Can you please look at the code in question and compare what is on your website to the below code?
https://git.drupalcode.org/project/schemadotorg/-/blob/1.0.x/src/SchemaD...
Maybe you need to reinstall/recopy the module via composer if these lines don't match.
apmsooner → credited jrockowitz → .
No one else has ran into this issue and there are no update hooks which delete configuration. You might have to revert to a back up to get the lost configuration and moving forward export your configuration before updating the module.
jrockowitz → created an issue.
Do you still have the YAML configuration for `schemadotorg.schemadotorg_mappings.node.place.yml` exported? Can you share it here?
My best guess is that some update hooks were not triggered, and the updated configuration was not exported.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → made their first commit to this issue’s fork.
Okay my mistake the issue is with the media_contextual_crop_iwc_adapter
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
I updated the project page based on your suggestions.
I had a few minutes to test this patch.
Below are my basic steps to review
- Check out the MR
- Clear cache
- Add custom field to page content type
- Create a link field using default values
- Create a link field that only shows URL, placeholder, attributes, etc...
- Confirmed default link field worked as expected
- Confirmed customize link field worked as expected
The most immediate minor issue I found was adding a new link field logged the below warning multiple times.
Deprecated function: Creation of dynamic property Drupal\custom_field\Plugin\DataType\CustomFieldLink::$value is deprecated in Drupal\Core\TypedData\TypedData->setValue() (line 102 of core/lib/Drupal/Core/TypedData/TypedData.php).
jrockowitz → created an issue.
I will promote my sandbox to a dedicated ECA report module, allowing people to contribute to it there. On the project page, I will reference this ticket.
If the consensus is that this functionality will eventually be integrated into the Modeler API and ECA (core), I could promote the sandbox to a project with the 'eca_report' namespace. The only downside of that decision is that we are establishing an 'eca_report' namespace, which might be around for only a few years.
Based on #11, the new modeler API can provide a plugin usage report. The ECA Report module adds some additional columns to the reports based on the plugin type.
It might make the most sense to postpone this and leave the code in the sandbox module AS-IS.
The \Drupal\eca_report\Controller\EcaReportBaseController::getUsedIn method is relatively basic and could be reworked to support the Modeler API. At the same time, in 3.x, the ECA entity is not being changed, so we might not have to tweak any code.
My hope is that we select an MVP solution that can be easily iteratively improved without requiring additional work for the ECA maintainers.
I do see that eca_ui.module is going to change significantly with 3.x, and maybe adding this report to that module is not the best approach.
I appreciate the immediate feedback.
For #2, similar to the Views plugin report, we should only list enabled plugins.
For #3, also similar to the Views plugin report, I added a 'Used in' to track an ECA plugin's usage.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
jrockowitz → created an issue.
@see 🐛 Remove deprecated SDC module dependency Active
jrockowitz → made their first commit to this issue’s fork.
jrockowitz → made their first commit to this issue’s fork.
We could implement the work-around inside the webform module if required.
The patch removes the expanded attribute which I think improves the accessiblity for screen readers.
Even though a machine/automated review says the tag + attributes is invalid, it does not mean we should remove the attribute to pass an automated test.
I am not sure this is resolvable. Changing the tooltip's HTML tag will cause visual regression on the sites targeting the SPAN tags. You might have to use the patch AS-IS.
The challenge will be adding Ajax callbacks to the widget.
@damienmckenna I am hesitant to add new features, but maybe this is simple to implement, and the variant dropdown is only visible if the webform is using variants.
The webform nodes 'References' kind of allows people to build nodes for different variants.
jrockowitz → made their first commit to this issue’s fork.
jrockowitz → changed the visibility of the branch 3517069-accessibility-issue-tabs to hidden.
This is most likely the future direction for external libraries.
✨ Create a mirror for external library dependencies for composer support Active
6.3.0-beta2
Please create an MR and lets see if the test pass.
I am not sure we can make this type of access control change without impact existing expectations.
People should weigh-in if this enhancement is useful.
jrockowitz → created an issue.
jrockowitz → created an issue.
I think the SchemaDotOrgFieldHelper does improve things.
The short answer is people have to upgrade to resolve this issue
I reverted the commit.
@BramDriesen My jaw dropped when I logged back in. I was about to re-roll the MR when I saw that you had already done it. Thank you!!!
We probably need to rebase this because of 📌 Convert to OOP Hooks Active
Your persistence has paid off. I am at DrupalCon is time to merge this. Thank you!!!
jrockowitz → made their first commit to this issue’s fork.