🇺🇦Ukraine @gilmord

We used this service: https://instant.page/

it prefetches links on hover

Hi, please create a fork and prepare a merge request, so I can review and merge it
thanks!

Here are instructions:
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

Views field configuration:

Result:

The "Fields that trigger ajax" - this is array keys of the widget form, you can check here how it is used:
https://git.drupalcode.org/project/editablefields/-/merge_requests/13/di...

And the "Event that will trigger an ajax" - is a javascript event to be bind to trigger submit

@tonka67 a few things to check:
- make sure you use the latest dev version of the module
- use Inspect Element in browser developers tools and check the event is attached to the field in the view

- if the event IS there and does not work - check the javascript console output, maybe there are some errors
- if the event IS NOT attached - please use xdebug or any other way to debug the inside of "foreach ($fields_ajax as $field_ajax) {" loop to check if the value you set in "Fields that trigger ajax" is in the $form

One more thing - for the cases when the entire view is wrapped in a form element (for example if you use Views Bulk Operations) you have to set the "Select behavior" of the field to "Form in popup" instead of the default "Inline form"

By the way visually all looks good - order is paid, user is charged, user sees no errors

I have noticed the issue when enabled commerce_stripe_webhook_event and checked the webhook logs at /admin/commerce/config/stripe-webhook-events

I checked the commerce paypal module, they create payment in the onReturn method of the payment gateway plugins:

Example 1

Example 2

Example 3

Looks like this part is missing for the Commerce Stripe and payment is created in "Payment process" pane and not on the onReturn of the gateway plugin

Here is my checkout flow:

I have added sleep(1) in StripePaymentElement::processWebHook which is a horrible solution but it works

checking on how the other payment gateways are dealing with the same issue

I use commerce core 2.38.0 and commerce_stripe dev-1.x, and I face this issue on every payment

gilmord → created an issue.

Thanks, looks good, works good, merged

Hi @rodrigoaguilera, good idea

A couple of suggestions:
- implement getter for protected $form_mode
- move getters above buildForm method, so we have all getters in one place

Thanks!

Thanks, released

Pushed 1.0.2, need testing

gilmord → created an issue.

Thanks!

merged into dev branch, it will get into the next release

$instance['label'] = '';

This code was in drupal7, it is not supported by the maintainers, so we can skip this unless comunity implement solutions for title/description for d7 version

Perfect, Entity Form/Display Field Label can now handle both title and description.
Looks like we do not need $instance['label'] = '' this code and can relay on external modules to interact with the wigets.

Thanks @paulrad, closing this issue.

This module relays on what you have configured in the form mode, ot dea not interact with the widget and only renders it.

Consider hiding description on the form mode level

See this issue as a reference:
https://www.drupal.org/project/editablefields/issues/3390633#comment-154... ✨ Ability to hide field label in views Active

You are looking for https://www.drupal.org/project/editableviews →

It wraps the entire view with the form

And this module keeps each field as a separate form, one submit will be hard to implement without hacks

@joelpittet yeah, my bad, it is a form mode indeed

Found this module, but have not tested it:
https://www.drupal.org/project/entity_form_field_labe →

I think we should use some eternal/core functionality to handle labels, as this module totally relays on what you have set up in your form mode and does not interact with the widget selected and only renders it based on form mode settings

This is far from perfect, but at least something
It works for the simple cases, and should be a good starting point

Thanks!

Merged in dev version

Merged in dev version

gilmord → made their first commit to this issue’s fork.

gilmord → created an issue.

bohart → credited gilmord → .

Thanks, released in 1.0.6
https://www.drupal.org/project/paragraphs_sets_plugins_ui/releases/1.0.6 →

Thanks, released in 1.0.6
https://www.drupal.org/project/paragraphs_sets_plugins_ui/releases/1.0.6 →

Thanks, released in 1.0.6
https://www.drupal.org/project/paragraphs_sets_plugins_ui/releases/1.0.6 →

gilmord → made their first commit to this issue’s fork.

gilmord → made their first commit to this issue’s fork.

gilmord → created an issue.

gilmord → created an issue.

Hi, submitted a MR review, please check

gilmord → made their first commit to this issue’s fork.

gilmord → created an issue.

In any case this does not seem to be a good approach to force domains. Imagine having millions of nodes and only small part of it is domain-restricted - node_access table will be flooded with millions of useless records. If there are translations - the number will be doubled/tripled/etc

I think this issue should be handled and it should not work like that by design.

For now, I have just disabled the hooks, works well so far.

/**
 * Implements hook_module_implements_alter().
 */
function YOUR_MODULE_module_implements_alter(&$implementations, $hook) {
  // Before the issue is resolved we disable access hooks
  // to allow content in all domains.
  // @see: https://www.drupal.org/project/domain/issues/3047514
  $disable_hooks = [
    'node_access_records',
    'node_grants',
  ];
  if (in_array($hook, $disable_hooks)
    && isset($implementations['domain_access'])
  ) {
    unset($implementations['domain_access']);
  }
}

Just faced this issue - I only need domain_access for users, all the content is shared between domains. I have deleted the fields but node_access table is still full of grants.

There is no built option to disable this module for content, content is locked to the active or default domain. According to attached issue I have to grant nodes to all domains which will make useless access checks as it always should be accessible.

I would say a propper option here is to disable grants and access records hooks so if domain_access is not needed for content it can be disabled.

@jmauricio thanks!

By the way I noticed interesting thing - this module successfully replace toolbar not only for Gin theme but for any theme.

In my case it worked for adminimal and for my custom theme.

Maybe we should consider replacing it with a global module, not limited to Gin theme

I did not dig why, but this patch (https://git.drupalcode.org/project/gin_toolbar_custom_menu/-/merge_reque...) + patch from related issue (https://git.drupalcode.org/project/gin_toolbar/-/merge_requests/38.patch) did the trick for me - I have regular adminimal toolbar on one domain and I have gin toolbar + custom menu for it on gin theme domain.

gilmord → created an issue.

Looks like having this hook is not enough to solve domain issues, as many of the hooks in the code are missing _gin_toolbar_gin_is_active check

gilmord → created an issue.

+

Hi, consider this module https://www.drupal.org/project/paragraphs_sets_plugins_ui → it has a working solution for a ui and yaml export

It is developed by me, I do not mind including it as a submodule to this one if this makes sense

Let me know if any adjustments should be done there

I will prepare a MR with a submodule

Changes in the Merge Request 9 looks good and fixed the rrror for me

+1 for this to be merged.

Hi, please try to hide the lable in the display mode you use for the editable fields

I recommend having a separate view mode to use for editable fields, not the "default" one

Does it make any sense to implement this?

Sitemap is basically used by bots and crawlers, which typically expect it to be located at /sitemap.xml and you have to point search engines manually if you have sitemap at any other location.

You can check this issue → and the related issues - it contains explanations why this module has the sitemap at /sitemap.xml

If you really-really want it to be at /en - I can suggest that you create a URL alias for /en/sitemap.xml to be alias for /sitemap.xml, optionally you can block access to /sitemap.xml using nginx for example. But do not forget to point the search engines where to look for your sitemap.

Also I do not think this is a bug or it is critical considering the attached Related issue explanations.

Hi @rodrigoaguilera can you please create a fork and open a merge request based on your patch?
Thanks!

makes sense for me, if the Metatag Views or the Simple XML Sitemap (Views) is enabled - I`d expect the display extenders to be enabled without changes to views.settings config

@jrockowitz looks like there are two MTs for some reason, this one looks fine:
https://git.drupalcode.org/project/webform/-/merge_requests/359/diffs

@jrockowitz not sure what kind of document is required, please give more details on it

As about how to replicate and fix the issue:
- Replicate: metatag_tokens() triggers hook_metatags_alter(), hook_tokens can be invoked by Drush (f.e. update hook to resave entites), so there is no route in this case
- Fix: make sure $route_name is not NULL in webform_metatags_alter() before using it

I got this notice when running tests, merge request !358 fixed it for me.
+1 for this to be merged

+1 for this to be solved, I face exactly the same issue with simple_sitemap also, looks like the problem is general and more likely related to core as multiple modules struggling with it

Attaching the issue in case it will be solved earlier

Same issue installing site on the clean database, views module has already higher weight than simple_sitemap_views

Merged, created 1.0.5 release with this cahnge.

Hi @Anmol singh

Please create an fork and prepare MR, thanks!

@zbberlin if clearing cache does not help - please share the error log (not the ajax error text, but the actual log - in the watchdog or in your server logs)

Does comment #4 resolve this?

Hi @larowlan
Number 4 seems to work - but this is a hack, you need to keep in mind to implement hook_entity_bundle_field_info every time you override a field with a validation constraint and re-add the constraints to the override.

For sure this should be automated, otherwise, developers will get into debugging hell trying to find why some constraints suddenly stop working at all.

Hi @mrcharles
Thanks, I have updated the module description to mention views_entity_form_field in the "Similar modules" section!

gilmord → created an issue.

Hi @honyik looks like some bug (or feature) of git.drupalcode.org
I tried a couple of other projects - download leads to the project page on drupal.org.

You can use git to download the files like this:

git clone https://git.drupalcode.org/project/pdf_using_mpdf.git

After that, you can switch the branch to the latest dev and use the files however you need.

Also, I am not sure you will be able to fix anything manually, as the required library does not work with the packages of the fresh Drupal installation, and the maintainer of the library is not willing to fix that.

Better look at the alternatives like dompdf, also modules like entity_print can work with various alternatives of the mpdf (if I remember correctly).

If you check how Geolocation + Address works - once you set the point on the map - address country is updated
Looks like this is the best option - instead of forcing the user to handle address it should be handled based on provider response

A boolean with three values (NULL, 0, 1) has no upside whatsoever. At least I cannot imagine a single example where it's nice or convenient to use a boolean field to find out if a user has saved his/her user profile, webform or some node.

Sounds right, but as far as a boolean is not just a value but a separate table - the problem appears, you have to JOIN the table to use it, and default join (INNER JOIN) will skip rows with unexisting values, and LEFT JOIN is much heavier to execute.

Just thought of one more workaround for you - you can add boolean field as a base property ( https://www.drupal.org/docs/drupal-apis/entity-api/defining-and-using-co... → ).
It can inherit all the benefits of the field but will be stored in the base entity table as single column. Like a "status" of the node.
I think this will simplify the queries as there will be no need to join the boolean table.

The bad side of this option - you may end up with many extra columns in the base entity table.

Hi @Steven Snedker

This question is not new, and it was discussed many times with the core contributors. Long story short - it works as designed (=

The "good" way for your case (get unchecked and never checked) will be to force 0 as a default value.
But here comes the problem - what if you add a boolean field to the existing entity? The problem appears when you have millions of existing entities.
It does not allow us to implement any fast filling of the values - it can get timeouts and staff like that.
So this has to be handled by the developer by adding batch processing, like Drush command or views bulk operation. There are contrib options for that - https://www.drupal.org/project/field_defaults →

I suppose this is the main reason we face empty values - as you can see here https://www.drupal.org/project/drupal/issues/1919834 → - it works as designed (you can check the thread to find explanations).

Another possible option is to use a query instead of an entity query and use the LEFT JOIN to relate the boolean field table.

@Anybody I did not know what branch has to be used as a base, so I used the one the fork created for me.
And it was an outdated branch, and the fresh one has a lot of changes.

Instead of rebasing we should consider reworking it, should be faster than rebasing from an outdated version.

Hi @cassioalmeida

Again - this makes no sense to push this issue

It looks like you are confused by the "Checkbox" form widget, as it looks the same for NULL and for FALSE
Please try using the Radio Buttons widget, and you will see the boolean field has actually 3 options:
- NULL
- FALSE
- TRUE

And only NULL is EMPTY, FALSE and TRUE are NOT EMPTY
and this is how the isEmpty() works now, and it is logical.
Treating the value FALSE as EMPTY is not logical.

Please see the attached image:
radios →

No matter how many times you edit a node, all those fields, if the field value is empty, the method isEmpty return true; if not, false.

This is the wrong statement. use Radio Buttons and set the field value to empty as many times as you want, not only once.

1-) Avoid custom code to check if the field is empty by accessing its value.

This is wrong also. You do not need to check value to know if the field is empty. You can use the isEmpty() method. If you want to check if the field value is FALSE - you HAVE to check the field value. Do not mix EMPTY and FALSE.

Please stop pushing this.

Rebase is required now, I will check it later

Hi, I have opened MR with the fix.

I used the patch as the base but did a small naming change, fixed the issue with the checkbox value not being saved and it is capable with the latest dev version.

Here is the patch:
https://git.drupalcode.org/project/rabbit_hole/-/merge_requests/25.patch

gilmord → made their first commit to this issue’s fork.

Hi @deku-dev can you give more details on what exactly you need?
Not sure what you mean by "change view mode", can you share some screenshots/videos?

Also, please use the forks instead of patches
Thanks!

@ivanpg94 please also share the configuration of the editable field formatted,
thanks!

Hi @ivanpg94
Does the issue occur only with the commerce entities?
Are nodes affected?