🇺🇸United States @hockey2112

I just now used the version from #36 on a D10 website. Worked fine. Here's the contents of the .info file:

name: Views Distinct
type: module
description: Allows filtering "distinct" Views result rows based on arbitrary fields.
package: Views
core_version_requirement: ^8.8 || ^9 || ^10
dependencies:
  - drupal:views

OK thank you for your patience, greatly appreciated!

hockey2112 → created an issue.

Is this a stable version now, or will a new version be released for D10 / 11?

I'm not sure I follow. Installation of the module auto-created a "donation" Order Item Type. Are you saying I need to create an additional Order Item Type, for example "donation_2", that will then be used in an additional Checkout Flow that I must manually create?

Maybe my disconnect is that I am expecting the donation route to use one flow, and normal ecommerce to use another flow. I don't want ecommerce customers to be able to "also donate" in the same checkout, and likewise I do not want donation customers to be able to "also order a product" in the same checkout.

With that personal requirement in mind, is that possible with this module?

I changed my setup to "Allow both". I also decided to uninstall and reinstall, in case something got "twisted up" during my original setup.

Here's what I've got:

/admin/commerce/config/donation-settings

"Allow both" is selected

Configuration for /donate route: 
OrderItem to use on /donate: Donation

Order to use with the OrderItem chosen above: Default
(I did create a new Order type called "Donation", but if I select it here and save, the setting simply reverts back to "Default". Bug? See the red arrows.)

Checkout Flow: Donation Flow

Configuration for /cart route: 
OrderItem to use with /cart | /checkout: Default

Order to use with the OrderItem chosen above: Default

Checkout flow: Default

I notice that the "both" configuration scenario states:

"You will need to create extensions of the donation and memorial panes that select for your additional OrderItem type, and use those panes in the checkout flow which you configure to use this second OrderItem."

What specific action do I need to take to do that? Or is that already done by way of me moving the "Add a Donation" item to the first step of the Donation Order Flow?

Thank you!

hockey2112 → created an issue.

Ah yes, that makes sense (and is somewhat embarrassingly obvious). Thank you!

hockey2112 → created an issue.

hockey2112 → created an issue.

Seeing the same deprecated info here as well

The problem is that these users are purchasing memberships. We don't want to have any users registered who are not members, and they must purchase that membership fee in order to become a member.

Is this functionality going to be rolled into the official release?

Experiencing the same issue.

Did you discover a solution for this? I am running into the exact same problem.

hockey2112 → created an issue.

Any schedule for a release for D10?

#9 worked great, thanks!

Were you able to find a solution for this? It currently redirects to the user Edit page, which is confusing because they just set their new password and now Drupal is giving them the option to immediately change their password. It should redirect them to the home page, or to the user View page.

hockey2112 → created an issue.

Did you find an alternative solution?

hockey2112 → created an issue.

Had to re-discover this method today. This link also helped: https://www.drupal.org/docs/user_guide/en/prevent-cache-clear.html#s-usi... →

Using the rebuild script
Open settings.php (/sites/default/settings.php) in any plain text editor. Add this line to the end of the file and save it:

$settings['rebuild_access'] = TRUE;
Visit http://www.example.com/core/rebuild.php in your browser (where www.example.com is your site’s URL). After a short pause, you should be redirected to the home page of your site, and the cache should be rebuilt.
Open settings.php (/sites/default/settings.php) in a text editor. Find the line you added with $settings[rebuild_access], remove this line, and save the file.

Yes I think that would fix the issue.

I believe it is outdated.

Ah, got it. Thanks for the feedback! I will adjust my workflow and my CSS accordingly.

hockey2112 → created an issue.

Very interested in this.

Workaround: I wasn't using the "Generational" field, so I relabeled that as "Nickname", and created a new format like this:

((((t+ig)+(i="s-")+im)+if))+jc

The bolded part adds the Generation/Nickname value in the proper location, wrapped in quotation marks (which are hidden if no Generational value exists).

hockey2112 → created an issue.

No, I don't believe I did. Pretty sure I just used colorbox inline instead.

hockey2112 → created an issue.

Anyone have a working solution yet? #30 does not work. I am working on a new ecommerce website, and was hoping there might have been a real fix for this issue in the several years since it was reported.

Looks like that worked, thank you!

hockey2112 → created an issue.

hockey2112 → created an issue.

Any updates on D10 CKeditor 5 compatability?

I just tried this command:

composer require 'drupal/animatecss_aos:1.0.x-dev@dev'

And it returns this error:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/animatecss_aos dev-1.0.x requires drupal/animatecss 1.1.x-dev@dev -> found drupal/animatecss[dev-1.1.x, 1.1.x-dev (alias of dev-1.1.x)] but it does not match your minimum-stability.
    - drupal/animatecss_aos 1.0.x-dev is an alias of drupal/animatecss_aos dev-1.0.x and thus requires it to be installed too.
    - Root composer.json requires drupal/animatecss_aos 1.0.x-dev@dev -> satisfiable by drupal/animatecss_aos[1.0.x-dev (alias of dev-1.0.x)].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

hockey2112 → created an issue.

hockey2112 → created an issue.

This was apparently what fixed a cron issue for me as well. Cron was running and would not complete or stop, and it was filling my logs with messages. I found this message on that site as well. Installed this patch, and cron is now successfully running and is not filling my logs any more.

hockey2112 → created an issue.

@bmango, I had to do another Drupal 9 > 10 upgrade today, and this module was once again causing issues. I followed your advice, and it worked like a charm. Here were my steps:

1. I moved the bg_img_field dir to the root dir, outside of the Drupal installation.
2. I removed the bg_img_field line from composer.json.
3. I ran composer update to upgrade to D10.
4. I then created a new dir at public_html/modules/manual and added the bg_img_field dir there.
5. I then ran update.php, and everything seems to be working great.

Thanks for your idea!

I am also encountering this issue in Drupal 10. For example, I am seeing "forum/1" instead of "forum/sports".

This is my path alias pattern:

forum/[term:parents]/[term:name]

Ignore my previous. I apparently had the "custom" version of this module from back when it was first created and provided in a core forum thread. To fix my issue, I did the following:

1. Back up my existing fees data
2. Uninstall the custom fee module (which required me to delete all fees)
3. Manually installed the contrib fee module, with the patch listed here.
4. Recreate my fees
5. Remove the outdated fee code from the Commerce PluginItemDeriver file

This fixed the same issue for me today. To clarify just a bit, the TransactionManager.php and Connection.php files are in code/modules/mysql/src/Driver/Database. As basby stated, you literally just copy everything from line 7 until the end of the file, and paste it at the end of the Connection.php file. I then cleared cache successfully and then reverted the changes in Connection.php back to the original version of that file.

hockey2112 → created an issue.

Checking in about this item, as it is blocking me from upgrading from Drupal 9 to Drupal 10.

The patch is #15 worked for me, thanks!

Interesting, thank you for looking into this. Hopefully a fix can be added sometime in the near future.

Hi, was this feature added?

hockey2112 → created an issue.

I also need a default setting for "open in new window"... in fact, it would be best (at least for me) if I could set that as default for all links and then disallow the end user from modifying that setting.

hockey2112 → created an issue.

hockey2112 → created an issue.

That's perfect, and I can't believe I missed it. Sorry for the confusion!

hockey2112 → created an issue.

The patch in #8 worked for me.

Same issue here. does not redirect when I have "email verification required" checked.

Thanks, this fixed the issue for me.

hockey2112 → created an issue.

Disabling the "protect all forms with Honeypot" setting fixed this issue for me, thanks!

Yes, even after I populate the field with a phone number. Screenshots attached. First screenshot is when I type the phone number. Then I click "proceed". Second screenshot is the error message that appears.

hockey2112 → created an issue.

hockey2112 → created an issue.

Thanks this seems to have fixed the issue I was having... when the "click to calculate discounts" button was clicked multiple times, it was allowing the discount to be applied more than once.

hockey2112 → created an issue.

hockey2112 → created an issue.

hockey2112 → created an issue.

Appears to be related to this issue.

Are both patches necessary to resolve this issue?

hockey2112 → created an issue.

Any word on this? I am looking for a way to search my orders based on the customer name, and I keep coming up against dead ends.

I am trying to use the custom module in #8 to allow my list of orders to be searchable based on the first or last name of the billing or shipping profile, but I am not seeing any way to add such a filter in my View. Can someone please direct me on where I can add that?

hockey2112 → created an issue.

#11 worked for me, thanks!

Here's what the host said:

we saw two mod_security rules that are being hit by mysite.com
We whitelisted the website from those rules.

[] Rule ID: 390709
[] Times Hit: 1
[] URLS Affected: /.env
[] Description: Atomicorp.com WAF Rules: Attempt to access protected file remotely

[] Rule ID: 340029
[] Times Hit: 7
[] URLS Affected: /views/ajax
[] Description: Atomicorp.com WAF Rules: Attack Blocked - command in REQUEST_URI or Argument

Does that mean anything to you?

Ah good catch, I will check on that.

Here's an odd thing though... the ajax functionality works fine in the View's admin screen. Would this indicate a theme conflict? I am using https://www.drupal.org/project/bootstrap_barrio →

hockey2112 → created an issue.

No progress on my end, but it is definitely still a need.

Ran into this again today on a different website. Can this be rolled into a new release of the module?

I should also say, if I make the changes directly to the template file within the module dir, the changes reflect on the website. However, I know that is not a valid best-practices way to make this change since it will be overwritten when the module is updated.

levmyshkin,

Thanks for your help with this!

1. Sorry, I should clarify. I am using a subtheme, so my template file is in /themes/contrib/themename_subtheme/templates/. But it is not taking effect on the front-end.

2. I created a module as you suggested. Here are the files I created, in /modules/custom/ept_enhancements:

ept_enhancements.info.yml
ept_enhancements.module
/templates
paragraph--ept-slideshow-item--default.html.twig

/modules/custom/ept_enhancements/ept_enhancements.info.yml:

name: 'EPT Enhancements'
type: module
description: 'Custom enhancements for EPT module.'
package: Custom
core_version_requirement: ^8 || ^9 || ^10
version: '1.0'

/modules/custom/ept_enhancements/ept_enhancements.module

<?php

/**
 * Implements hook_theme_registry_alter().
 */
function ept_enhancements_theme_registry_alter(&$theme_registry) {
  $ept_module = 'ept_enhancements';
  $module_path = \Drupal::service('extension.list.module')->getPath($ept_module);
  $base_theme = 'paragraph';

  $theme_registry['paragraph__ept_slideshow_item__default'] = [
    'path' => $module_path . '/templates',
    'template' => 'paragraph--ept-slideshow-item--default',
    'render element' => $theme_registry[$base_theme]['render element'],
    'base hook' => $base_theme,
    'type' => 'module',
    'theme path' => $module_path,
    'preprocess functions' => $theme_registry[$base_theme]['preprocess functions'],
  ];
}

/modules/custom/ept_enhancements/templates/paragraph--ept-slideshow-item--default.html.twig

{#
/**
 * @file
 * Default theme implementation to display a paragraph.
 *
 * Available variables:
 * - paragraph: Full paragraph entity.
 *   Only method names starting with "get", "has", or "is" and a few common
 *   methods such as "id", "label", and "bundle" are available. For example:
 *   - paragraph.getCreatedTime() will return the paragraph creation timestamp.
 *   - paragraph.id(): The paragraph ID.
 *   - paragraph.bundle(): The type of the paragraph, for example, "image" or "text".
 *   - paragraph.getOwnerId(): The user ID of the paragraph author.
 *   See Drupal\paragraphs\Entity\Paragraph for a full list of public properties
 *   and methods for the paragraph object.
 * - content: All paragraph items. Use {{ content }} to print them all,
 *   or print a subset such as {{ content.field_example }}. Use
 *   {{ content|without('field_example') }} to temporarily suppress the printing
 *   of a given child element.
 * - attributes: HTML attributes for the containing element.
 *   The attributes.class element may contain one or more of the following
 *   classes:
 *   - paragraphs: The current template type (also known as a "theming hook").
 *   - paragraphs--type-[type]: The current paragraphs type. For example, if the paragraph is an
 *     "Image" it would result in "paragraphs--type--image". Note that the machine
 *     name will often be in a short form of the human readable label.
 *   - paragraphs--view-mode--[view_mode]: The View Mode of the paragraph; for example, a
 *     preview would result in: "paragraphs--view-mode--preview", and
 *     default: "paragraphs--view-mode--default".
 * - view_mode: View mode; for example, "preview" or "full".
 * - logged_in: Flag for authenticated user status. Will be true when the
 *   current user is a logged-in member.
 * - is_admin: Flag for admin user status. Will be true when the current user
 *   is an administrator.
 *
 * @see template_preprocess_paragraph()
 *
 * @ingroup themeable
 */
#}
{%
  set classes = [
  'paragraph',
  'paragraph--type--' ~ paragraph.bundle|clean_class,
  view_mode ? 'paragraph--view-mode--' ~ view_mode|clean_class,
  not paragraph.isPublished() ? 'paragraph--unpublished'
]
%}
{% block paragraph %}
  {% block content %}
    {% if content.field_ept_slideshow_link|render %}
      <a href="{{ content.field_ept_slideshow_link.0['#url'] }}">
        {{ content.field_ept_slideshow_slide }}
      <div class="ept-slideshow-content">
		  {{ content.field_ept_slideshow_title }}
		  {{ content.field_ept_slideshow_text }}
	  </div>
      </a>
    {% else %}
      {{ content }}
    {% endif %}
  {% endblock %}
{% endblock paragraph %}
{{ attach_library('core/drupalSettings') }}
{{ attach_library('ept_slideshow/flexslider') }}
{{ styles|raw }}

And here is the result (attached screenshot). As you can see, the new template file is still not reflecting any changes on the website. I'm not sure if I am just missing something obvious, or what...

hockey2112 → created an issue.

I switched my theme to Olivero, and sure enough the link attributes we displayed. I then changed to Bootstrap Barrio base theme (which I use in conjunction with my Barrio child theme), and the link attributes were not displayed. So it appears it must be an issue with Barrio. Very strange, because I use this module in pretty much all sites that I build and it has always worked with those.

You are correct, upgrading the module did the trick. Thank you!

hockey2112 → created an issue.

hockey2112 → created an issue.

Is this patch all that is needed to make this module Drupal 10 compatible? When I examine the module using the upgrade_status module, it returns several issues/reasons for not being D10 compatible.

File name Line Error
C:\xampp\htdocs\mysite\public_html\modules\custom\commerce_fee\commerce_fee.post_update.php 15 Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

C:\xampp\htdocs\mysite\public_html\modules\custom\commerce_fee\commerce_fee.post_update.php 26 Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

C:\xampp\htdocs\mysite\public_html\modules\custom\commerce_fee\src\FeeListBuilder.php 21 Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

C:\xampp\htdocs\mysite\public_html\modules\custom\commerce_fee\src\FeeStorage.php 49 Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

C:\xampp\htdocs\mysite\public_html\modules\custom\commerce_fee\src\Form\FeeForm.php 23 Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

hockey2112 → created an issue.

How about "hasevent" and "noevent" as the class names?

Still hoping for this feature. Can this be added?

The patch in #25 worked for me.

I just checked again, and I do not see the blocks. The reason I did not see them previously is because the block name was listed differently in the list of blocks. Instead of "test", it is listed as "themename_test". Other blocks are listed with just their name, and not the theme name. Not sure why there is this discrepancy, but hopefully my error will help others realize this in the future.

hockey2112 → created an issue.

The method mentioned in the original post worked for me on Drupal 10.

hockey2112 → created an issue.

Thanks, #4 worked.