🇨🇦Canada @liquidcms

Patch from #41 on -beta1 rather than latest -dev fixes pager as well as facet exposed filters. Still doesn't apply with 🐛 Disable updating the facets after each facet selection for Apply/Reset facet buttons block. Needs work but i'll redo that patch.

To fix facets break ajax paging (since upgrading core from 10.0 to 10.2); i upgraded Facets fro 3.0.0-beta1 to today's 3.0-dev.

Had to remove patch from here: 🐛 Disable updating the facets after each facet selection for Apply/Reset facet buttons block. Needs work as it no longer applies. Dev release does fix the issue with ajax paging however i no longer have a Views facet plugin. All views which had facet filters now show broken/missing handler.

I'll try going back to -beta1 and just using latest patch from here.

This doesn't apply to 3.x-dev version of facets.

liquidcms → created an issue.

I have a node display that has a field group (with label) wrapped around an EVA (a view meant to show up as a field on node display form). When the view returns no results i am left with:

<div class="section">
    <h2>Order Information</h2>
    <div class="views-element-container"></div>
</div>

Neither patch here or one from #3098550: Nested groups render on other entity forms (or when fields are inaccessible) when they shouldn't → solves the issue. I guess simply a striptags before determining emptiness is too simple?

liquidcms → created an issue.

Turns out this was getting broken by some other js library we load. I am digging in to see where the interaction is.

I think this would support what i am trying to build. I want to have one widget/star/whatever that when a user clicks it, it adds 1 to the vote total. And, if they click it again, it removes their vote.

With latest version of fivestar i get a star and an X. Not ideal but i could make that work with css. But selecting the X (to cancel) does nothing. Adding this patch changes nothing.

I also am not sure what the option for 0 stars would do or if it is required for the solution discussed here; but i don't have the option of 0 stars when configuring the field.

I agree this feature seems pretty basic and doesn't seem to be properly supported.. but, it is there. When i placed the field using a view and select to show Average vote for "Text to display under stars" it shows "Average 1 (4 votes)". The 4 votes is the total. Y could alter the summary template to remove the average part.

Sadly though, the Cancel your vote doesn't work.. different issue.

liquidcms → created an issue.

Thanks for that. Our commerce_orders view doesnt have that display so perhaps it got deleted somehow early on in the project.

And yes, assigning path to my custom order view does override the ListBuilder page.

This was originally reported for 2.17, but i just checked for 2.33 (close to latest) and:
- admin/commerce/orders as being discussed here, i am pretty sure is an entity ListBuilder page (not a view)
- admin/commerce/orders/list - as added into discussion by jsacksick, does not exist on my site.

I think making a view page to be at same url as the ListBuilder one may override the ListBuilder page. I'll test.

liquidcms → created an issue.

Not sure if this will be seen, as marked closed. Just setting this up and have a thumbsup widget which goes up on click and removes the user's vote if clicked again. My issue is i need to do a reload of the page to be able to vote a 2nd time (either undo or redo).

I could have sworn i had this working (could toggle back and forth with no page loads) last week.

liquidcms → created an issue.

liquidcms → created an issue.

dead link

All this work to change how the TZ list is generated; but still no way to alter the list?

How is this list overridden?

With the old system_time_zones() function i hacked in a patch to add an alter (which i could then use to alter the list). I assumed if this was being redone the ability to alter the list would be included; but i don't see it here. Am i correct that this class can not be overridden?

patch for code from #2

rather than try to sort out the issue with using the correct data selected in the field config; i created a separate view using the child paragraph as the base. Then using the https://www.drupal.org/project/views_field_view → module to embed this in my original view. Not ideal from a performance perspective; but works well.

I changed the title to better describe the issue here. Basically 2 issues:

1. generic entities are not supported (easily fixed with code posted above).

2. related content not supported.

For #2 i went through the render code and it is not correct for handling related content. The module's custom views field does have a setting to select which field is used to get attached entity id for the entity which has the rate widget; but this information is not used in the code. It gets the entity from the base entity of the result row. Of course views doesn't make this easy for us to get row result but it is available. I'll see if i can figure out how to properly access it. The other missing piece would be that i am not sure the view result would know the entity type that the id value is for. It may only know the row base entity (which is what the code currently is using).

My other option would be to try to arrange my setup so that the views base paragraph is the one being voted on rather than its parent; but certainly easier if this module supported related content.

i fixed the id not listing the views fields but thee are bigger issues here when trying to render the widget. Basically it looks like the code tries to simplify not requiring relationships.. but then doesnt take into account related data.

For example, my view is listing paragraphs but i am trying to vote on a paragraph which is a child of that main paragraph. I have the correct pid as my field that i use in the widget settings; but in the render code it doesnt use this and ends up using the parent pid. I'll sort this out on Monday.

There is no hook_views_data defined. Which poses some questions:

- not sure why this does seem to work for Nodes, just not other entities (like Paragraphs)
- project page reports over 2k sites using this module.. is it possible not one of those is on a non core entity?

Also, i am surprised that the rate.views.inc file is loaded on its own (it does seem to be; just didnt know that was a thing).

So adding this code to rate.module (or i guess rate.views.inc since it seems to get automatically loaded) does provide the Rate widget field for a Paragraph view:

/**
 * Implements hook_views_data().
 */
function rate_views_data() {
  $data['views']['rate_widget_field'] = [
    'title' => t('Rate widget'),
    'help' => t('An instance of a Rate Widget.'),
    'field' => [
      'id' => 'rate_widget_field',
    ],
  ];
  return $data;
}

but it still doesn't work as there are no options to set the column which holds entity id. I'll sort that out next.

liquidcms → created an issue.

Patch applies to latest dev and mostly works. The "title" is being set but the metatitle is still showing as the title used to create the page.. which doesn't seem to be editable.

liquidcms → created an issue.

Core will never replace what this module does. This module (in D7) has the ability to combine fields and use those for uniqueness. Core will never do that.

liquidcms → created an issue.

This patch adds weight to commerce_fee_field_data. A couple issues:

- didnt sort out how to update the entity. i have seen various posts on doing this but none seem to work. After this patch i need to run "drush entup" (but this isn't core to drush)
- the weight field is currently modifiable on the fee form; but ideally this would be a draggable ui on the fee list.

liquidcms → created an issue.

Ah, this isn't per content type, it is per field instance. Yikes, that is going to take some time to configure.

Thanks for this, hadn't realized i would need to enable for each content type. Although going to edit of any of my types and there is no option to enable. :(

@#13, and it works? I dont see anything in this post suggesting it was updated to work with V2/3, and 1 and 2/3 are definitaly different enough that this module could not work with both. The error i get with v3 when trying to assign a node to a group (what is difference between add/assign??):

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "plugin.manager.group_content_enabler". in Drupal\Component\DependencyInjection\Container->get() (line 157 of core\lib\Drupal\Component\DependencyInjection\Container.php).

Drupal\group_vbo\Plugin\Action\GroupVboBase::create(Object, Array, 'assign_to_group', Array) (Line: 21)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('assign_to_group', Array) (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance('assign_to_group', Array) (Line: 128)

liquidcms → created an issue.

I see the same issue on 4.0.0-alpha3

Just a comment to future self when i come looking for this again. Twig debug breaks being able to select items in the media browser.

liquidcms → created an issue.

I modified the patch from #99 to not include userinfo endpoint.

There is a userinfo endpoint option of "Alternate or no endpoint". We are using Azure's Common API (stupid name for an app which acts as a router to multiple AAD tenants). So far we do know of a userinfo endpoint so we picked the no endpoint option; but then this would leave the endpoint value empty (if filled in, auth fails as it fails trying to access the non-existent endpoint). But, if left empty, this fails the conditions for allowing autologin.

For now we have simply hacked out that condition; but possibly a more thought out solution here? I suspect the thinking was that all the "other" endpoints had to be filled in; but likely not that one.

my bad. i see autologin is not a committed feature. i'll post this issue there.

liquidcms → created an issue.

Thanks for this.. will try it out.

liquidcms → created an issue.

liquidcms → created an issue.

Drupal 6, Commerce 6. Can't say for sure but its very likely this isnt fixable. It may not be entirely a Drupal 6 issue or your site. Its quite possible that api's these modules rely on may no longer be available or even AMP (PHP specifically) release versions. Can you post any sort of description on what your issues are and maybe even error messages you may be getting? I get this is the "hire a dev" area and not the "debug issues area"; but in this case (i.e. very old code), it might be valuable for people to decide if they can support you.

Although i think our solution is no longer needing this patch, i did try to debug what it was doing. I think the method $display_handler->usesExposedFormInBlock() isnt doing what is intended here. I think it is only testing if this is an option; not the value of the option. So even though i don't have my exposed form in a block, this is returning true regardless and the code fails because the next line: $form = $display_handler->viewExposedFormBlocks(); returns null (since i do not have this enabled). This causes my error.

Also, is the work here not the same as being looked at here: ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work ?

Yes, removing this patch and my facets exposed filters (not in a block) combined with other views exposed filters now works correctly on all environments. Of course the places where i use exposed views filters in blocks, no longer work with ajax. PErhaps this patch needs to only apply where needed? I'll take a look at that tomorrow.

I have facets 3.x and this patch working well to provide a views exposed facet filter (mixed with other exposed filters). It works on our local dev environment as well as Dev server environment. But for some reason i get this ajax error from our staging environment:

Trying to access array offset on value of type null in /var/www/html/core/modules/views/src/Controller/ViewAjaxController.php on line 214

the error is from code added by this patch. Checking the html source and there is a [data-drupal-selector={$form['#id']}] attr. Any thoughts on what is causing this?

A little unclear but it seems like this patch may only be for cases where exposed filters are in a block; but Facets 3.x to combine with other views filters; this is not supported. The filters must be part of the view - not exposed in a block. I"ll test without this patch; although we also have instances on other pages where we do use filters in an exposed block (with ajax).

Also, not sure what your numbering is for the patch in #16 - it is supposed to use the issue nid: 3090504. What is 13327307?

liquidcms → created an issue.

Maybe someone can tell me if this is adding what i am looking for. Currently i have upgraded to Facets: 3.0.0-beta1 as we are trying to combine facets with other views exposed filters, and then use Ajax to submit.

I have my View set up for this as well as the patch from #21. To be clear, this is a "facet views filter" showing as part of the view (as opposed to placed as a separate block - which is not yet supported for Ajax submit).

With this i still have clicking any facet checkbox doing a page load. So it seems like both parts of this do not work:
- don't submit on checkbox select (this patch)
- submit using ajax (3.x)

That was almost a year ago.. so don't recall. But, i checked the couple projects i have on the go from back then and i don't specifically require that package and it isnt in my vendor folder - so perhaps the way i got around it was to remove it.

liquidcms → created an issue.

So the options at the moment are:
- patch commerce (#8 doesn't apply to commerce 1.37)
- patch entity

OR, i guess simply leave Commerce PayPal enabled.

just had to change the getPlugins method:

  $plugins = $group->getGroupType()->getInstalledPlugins();
  foreach ($plugins as $plugin_id => $plugin) {
    if (str_replace($group_type . ':', '', $plugin->getConfiguration()['id']) == $entity->bundle()) {
      $group->addRelationship($entity, $plugin->getConfiguration()['id']);
      $company = $group->get('label')->getString();
      \Drupal::messenger()->addMessage(t('%content added to %company: %company', [
        '%content' => $entity->getTitle(),
        '%company' => $company]),
        'notice');
    }
  }

although i am guessing it isn't necessary to loop through all the plugins to do this.

liquidcms → created an issue.

With 1.x i (think) i had to check if there was a valid ContentPlugin and then use this:

$group->addContent($entity, $plugin->getConfiguration()['id']);

is this no longer needed?

this doesn't make sense:

  $group->addRelationship($node);
  $group->addRelationship($node_type);

is $node_type a typo?

I'm tempted to simply add this line in OpenIDConnectRedirectController.php

    // @see \Drupal\openid_connect\OpenIDConnectSessionInterface::saveDestination()
    $session = $this->session->retrieveDestination();
    $destination = $session['destination'] ?: $this->configFactory->get('openid_connect.settings')->get('redirect_login');

    // Add Alter to allow modules modifying the destination.
    $destination = $this->moduleHandler
      ->invokeAll('openid_connect_login_redirect', [$destination])[0];

but suspect some method already exists to do this?

liquidcms → created an issue.

Thanks @msti for answering. Your patch no longer applies to the 3.2 branch; plus i don't think they handle redirecting the same way now (although don't see any way of altering this either).

I see my loop was caused by the modules login redirect set to /user, which for anon, redirects to /user/login (drupal core). Tghis is what then triggers the autologin again.. and the loop. Changing the login redirect to / (home page) and this now works as expected.. but still.. likely improvement to be had here:

1. does it make sense to redirect to the "login" redirect when the user isn't logged in? Perhaps there should be a login redirect and a login failed redirect (as i mentioned above).
2. also as mentioned above, i think supporting tokens or callbacks in these redirects greatly improves support for end cases.

liquidcms → created an issue.

liquidcms → created an issue.

latest (and most here) patches do not adhere to Drupal coding standards. Unclear why these would pass the test bot.

I think John's comment above that this has noting to do with views caching is correct. But i am not sure the answer is to make this a group content view and add in node context. My guess is this is fine for a view of only group content. My use case is users have a mix of group and non-group content. I think that solution breaks this.

What is likely needed is for my view to be a node view (since i am listing nodes), which then seems to be unaware of group limited node access, and then add something to give it group context so it can include group permissions limiting node access.

My solution so far to extend upon what is listed above is to remove SQL rewrite from the view (which then gives group admins ability to see more items than they have access to) and then added a views_pre_render hook to remove items from the list which do not have node_access. This works and mostly completes what i am trying to do here (limit views list and node access the same) but it does break paging.. so possibly a cleaner solution?

A few years later.. but same issue.

D9.5.11/G3.2.1

A (content/node) view listing a member's articles. Some in group, some not in group. The member can see both group and non-group content authored by the member; but the group admin cannot see the member's group articles (or their non group articles, but that part is correct).

I am able to get close by adding the Content Access module (because Drupal doesn't provide View Own permission) and this patch for Group to provide View Own: ✨ "View own" permission Needs work .

Now, members can see their own content (both in/out of group) and group admin can see only member content which is in the group. Perfect. But my view for listing the content still shows nothing for the Group Admin. I can see the view page but no titles are listed. But at this point i guess this is more of a core/views issue than a Group issue, isn't it?

A little more detail.

- with Group Admin set to View Any, the Admin can see the actual Policy nodes; but they do not show on the view (a Views/Group bug)
- there is no View Own so not possible to set this for the member, but they do not have access to their own group nodes (Group bug)
- setting Member to View Any and it then matches the Group Admin: can no see own node pages but items do not show in the view.

liquidcms → created an issue.

Unfortunate this was closed as what ended up in 9.5 does not work. The solution from #20 does work for us.

No, it does seem like this patch is putting the views field ids back as they were in D9 __revision_id. Yay!

Couldn't find a patch here that worked with 10.0.11 so attaching one here. It is based off the patch from #168.

I know this is closed and I am late to the game here; but do I have this right?

In D10 historical fields in views were changed from __revision_id to -revision_id. There was no updb script for this, so when i migrated to D10 a bunch of views now have broken/missing handlers. And then, once i go through and fix all of these by re-adding all these fields, all the rewrites are broken because twig can't handle the new field values in its tokens?

And the fix here, is to preprocess the twig token values and put them back to what they used to be (D9)? Silly question, but wouldnt it have been easier (and not broken a ton of sites) to just change the field ids back to what they were?

That being said, anyone know if any of these patches apply to D10.0? Haven't found one yet. :(

Not sure what #35 patch is as it refers to code which doesn't exist. To get this working for D10 i took the version i was using in D9 (1.3) and the patch i was using from here (#19) and simply made it D10 compatible by removing the composer.json file and setting core_version_requirement.

Not quite the proper path forward i suspect but unclear the direction here.

Anyone know the status of this?

We had it working on D9.5 but it does not work for D10. I see the patch has code which references: \Drupal\entity_field_condition\Subform\SubformHelperFactoryInterface but this doesnt exist in the 1.x or 2.x branches.

Is it just this patch required for this? Read (way) above that there might be a context patch also required (but if that was the case it would likely be mentioned in the OP).

I have D10.0. The patch from #192 is the most recent which applies. The functionality is there so far as the Control Visibility contextual link is there. Opening it (now) gives me a list of plugin options (it used to be a selector). Selecting Node Field and i get a constantly spinning throbber with what looks like the right form:
- node type (it doesnt know i am on LB for a specific bundle)
- Field
- value source
- etc.

When i pick my node type, the throbber stops but the Field field disappears.

Is it possible this part is simply not supported by core (which would be silly of course as fields are core)? I was previously using a patch to the Entity Field Condition module (i suspect in conjunction with the work here) and that patch is no longer compatible with D10; so i removed it thinking possibly covered by the work here.

liquidcms → created an issue.

I have a custom form open in a modal that i think has been working Well. Recently noticed the overlay appears but modal is hidden. Any slight manual reside of the browser window makes it appear.

It seems to be more of an issue with FF than with Chrome; but have intermittently seen the issue with Chrome.

It seems to reliably work for Anon users (but not for admins).

Disabling Back To Top and it seems to reliably work. Which is odd as BTT is there for Anon.

I've created a 1.1.x branch to be compatible with D9/10.

This includes the rector auto fixes from here and also fixes the use of twig/extension which is deprecated and replaces with twig/extra-bundle. I have also added a composer file to require the twig/extra-bundle.

NOTE: i have not tested the actual functionality of these changes. Will do the parts which we use this for once we have finished upgrading remainder of the site to D10. I don't know all of what this modules does; so hopefully someone else can report any issues.

Anyone know the status of this? Its tagged as Needs Work but looks as though this may be in 1.1.0.

lots of mistakes here... many places where example command is something like:

$response->addCommand(new SetDialogTitleCommand($selector, $option_name, $response));

$response is obviously not a parameter in these cases, it would be the the option value. I've been to this page many times and never noticed these before; so possibly recently broken?

spoke too soon. With the fix from #2, i still see this issue.

I am getting the same issue. process command hangs. --debug doesnt help; still no output.

This is:
- Windows 10 (in a git bash shell)
- php 8.1.13
- rector 0.15.25
- drupal 9.5.10

Group is installed but not enabled.

Just stumbled upon what I am sure is also due to this bug in Paragraphs.

I am using the Rest Web services (core) module to output rendered content of my nodes. This automatically spits out a json "array" for all enabled languages. This works great - except of course for paragraph content when it spits out EN content regardless of the language.

patch from #14 fixes for me as well.

with a very small sample size of testing (since it wasn't consistently occurring); this seems to have fixed the issue.

I am occasionally getting this on a D9.5.3 site. It was consistently working for many months but has recently been broken. Originally i thought it was only admin users using Firefox as it seemed to always work in Chrome or for non-admins. But just now i see the issue for a non-admin in Chrome.

This patch does not apply. Will try manual patch.

I have used Conditional Fields module to make a field group visible (or not) and can confirm that once the FGis made visible; all the fields within it are made required. The red star even shows on the label for the FG itself.

We just released code which syncs user accounts to Active Directory accounts. Shocked to see that 20% of our site's content was also deleted as one of the editorial team had recently quit the group (so no longer listed in AD). Never knew about user_cancel() but if it's required at all, should the default case not ALWAYS be to NOT to delete content?

Looking at what all else was wiped; although this editor also created a lot of taxonomy terms and even though those are not specifically tagged with an owner; they do, for some reason, have a translation owner. But those did not get deleted. Nor did any of his blocks. So seems a bit inconsistent - and silly.

As it is somewhat related; i never understood the options when using the UI:

• Disable the account and keep its content.
• Disable the account and unpublish its content.
• Delete the account and make its content belong to the Anonymous user. This action cannot be undone.
• Delete the account and its content. This

action cannot be undone.

- Why an option to assign to Anon? Would this not give anon access to all this content (perhaps not?).

- Why is the obvious (and preferred default) option not even listed here: delete user and assign to UID 1?

In my ssc_workflow example below i had not included all the fields in my .schema as I thought i may have only needed the ones which were translatable. I added all of them as this:

ssc_workflows.settings:
  type: config_object
  label: 'Workflows settings'
  mapping:
    stale_delay:
      type: text
      label: 'Stale delay'
    archive_delay:
      type: text
      label: 'Stale delay'
    archived_banner:
      type: text_format
      label: 'Archived banner'
    dmc_email:
      type: text
      label: 'DMC email'

Drupal\config_translation\FormElement\TextFormat->getTranslationElement(Object, '', '') (Line: 19)
Drupal\config_translation\FormElement\TextFormat->getSourceElement(Object, '') (Line: 64)
Drupal\config_translation\FormElement\FormElementBase->getTranslationBuild(Object, Object, '', '', Array, 'archived_banner') (Line: 57)
Drupal\config_translation\FormElement\ListElement->getTranslationBuild(Object, Object, Array, Array, Array) (Line: 178)
Drupal\config_translation\Form\ConfigTranslationFormBase->buildForm(Array, Object, Object, 'ssc_workflows.settings', 'en') (Line: 26)
Drupal\config_translation\Form\ConfigTranslationAddForm->buildForm(Array, Object, Object, 'ssc_workflows.settings', 'fr')

The definition of translatable configuration seems flaky. Going by this document I ended up with this for one module in the .schema.yml:

ssc_common.settings:
  type: config_object
  label: 'SSC+ configuration'
  mapping:
    login_page_h1:
      type: text
      label: 'H1'
    login_page_info:
      type: text
      label: 'Login page info'
    comment_login_info:
      type: text_format
      label: 'Comment login info'

ssc_workflows.settings:
  type: config_object
  label: 'Workflows settings'
  mapping:
    archived_banner:
      type: text_format
      label: 'Archived banner'

And while this is being considered.. how about a better way to pick the Parent than scrolling through the 1000 items listed in the drop down?

Same issue with generic D9.5 site.