🇦🇺Australia @thursday_bw

thursday_bw → created an issue.

I don't see a problem with linking to https://www.drupal.org/node/178772 → it cuts to the chase. I don't see any usability issues as the link text
is already semantic. This URL is indeed unchanging so it the safest bet.

I also agree with

Think the conversation about removing the links could be done in a follow up, as it may take time to discuss.

Let's discuss that in a follow up. By using https://www.drupal.org/node/178772 → as the href in this issue we can move
the conversation about what the best alias is for updates module page out into the documentation page too and get this issue closed off.

Derek, thanks for your work and keeping up to date and on top of this.

thursday_bw → created an issue.

Oh, I just experienced this, I have just installed matomo on my development site and I had a typo in both the http and https URLs.

I got "This website encountered an unexpected error" and had to view my PHP error log to see the same error as reported above.

Uncaught PHP Exception GuzzleHttp\\Exception\\ConnectException: "cURL error 6: Could not resolve host: mispelledsubdoman.example.com (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for http://mispelledsubdoman.example.com/matomo.php" at /app/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php line 210, referer: https://mispelledsubdoman.example.com/admin/config/system/matomo

Adding this comment, and following the issue, I'll try and do a review if I find some time.

Updated issue project: I moved this from the "Drupal core" project to the "Drupal core ideas" project.

I have changed this issues project from 'Drupal core' to 'Drupal core ideas'.

I have made changes to the merge request:

• Change help text from "See the Update module documentation for more." to "See the Update module documentation for details."
• Change help text from passive to active voice: "When checking for updates, anonymous information about your site is sent to Drupal.org." to "When checking for updates, your site automatically sends anonymous information to Drupal.org."

I have also updated the issue to reflect that those tasks are complete.
I have updated the issue to reflect that @dww and myself are in agreement to leave the location of this help text on the fieldset. It is indeed scope creep as suggested by @benjifisher and we can open a follow up item if we desire to improve on this.

I have set the status to "Needs Review"

Should the "needs documentation updates" tag be removed now? as it no longer needs the updates, they are done.

Updating "Proposed resolution" in the description to suggest the text as suggest by @quietone

Setting this back to active as the documentation we were waiting on so as to link to it is live now: https://www.drupal.org/community-initiatives/drupal-needs-review-queue-i... →

Replaced references to sub-maintainer with subsystem maintainer as per review comment in slack

'sub-maintainer' is not a role in Drupal core. I think this is referring to 'subsystem maintainer'.  I think the doc should use the roles defined in core governance, https://git.drupalcode.org/project/governance/-/blob/main/drupal-core.md?ref_type=heads

Replaced reference to "Exception handling" with "Excluding review bot" as per review comment in slack.

Exception Handling with "no-needs-review-bot" Tag:

I had to read this twice because exception handling means something else to me.

Add the CMI 2.0 candidate tag, and adding the CMI 2 initiative proposal as a related issue.

Updating to reflect that the Configuration installer → has been deprecated in favor of Installing Drupal from configuration (only certain profiles) →

thursday_bw → created an issue.

adding link to the second round of documentation changes to the issue description.

OK. You can view the changes to the Update manager module's Documentation here → in now reflects the usability team's feedback in comment #14 ✨ Add link to Update module documentation about installer settings Needs work

Updates include:

1. **Clarify Anonymous Information**: Repeat or refer to the section explaining the sending of anonymous usage statistics to Drupal.org to clarify what "anonymous information" entails in the new documentation.

2. **Consistent Terminology**: Use "Site maintenance account" instead of "site administrator" or "admin user" to align with the terms used in the installation form.

3. **Focus on Update Manager Module Configuration**:
- Explicitly state in the introductory paragraph that the options selected during installation can be changed afterward.
- Avoid repeating information about the options' roles in security or their functionality, focusing instead on how these options enable and configure the Update Manager module.

Updating to reflect the documentation enhancements that were recommended ✨ Add link to Update module documentation about installer settings Needs work as recommended by the usability review team
at the  Drupal Usability Meeting 2024-02-23  📌 Drupal Usability Meeting 2024-02-23 Active

• The documentation page already says, "... in order to provide this information, anonymous usage statistics (consisting of a unique key and a list of versions of the software your site is running) are sent to Drupal.org". The new section should repeat that or refer to it, in order to explain what "anonymous information" means. The text you added includes, "... your site automatically checks for the latest updates, keeping your site secure and up to date without manual intervention", which is not accurate.
• In order to avoid confusion, the documentation page should use the same terms as the installation form: "Site maintenance account" instead of "site administrator" or "admin user".
• The new section of the documentation page should focus on the fact that the options on the installation form enable and configure the Update Manager module. In particular:
  • In the introductory paragraph, explicitly state that the choices can be changed after the installation process.
  • Do not repeat information on what the options do, such as how they are important for security.

Updates include:

1. **Clarify Anonymous Information**: Repeat or refer to the section explaining the sending of anonymous usage statistics to Drupal.org to clarify what "anonymous information" entails in the new documentation.
   
2. **Consistent Terminology**: Use "Site maintenance account" instead of "site administrator" or "admin user" to align with the terms used in the installation form.

3. **Focus on Update Manager Module Configuration**:
   - Explicitly state in the introductory paragraph that the options selected during installation can be changed afterward.
   - Avoid repeating information about the options' roles in security or their functionality, focusing instead on how these options enable and configure the Update Manager module.

change status to 'needs work'

OK. I didn't update the issues (though I did think I had, trying again).

I spoke with @benjifisher in the #ux channel in slack about 1. The help text applies to the first checkbox, so it should be moved to a description of that option, rather than a description of the fieldset.

Here's what @benjifisher had to say

IIUC (If I understand correctly), the first checkbox enables the Update Manager module. The current text depends on whether the module is enabled or not:
> When checking for updates, anonymous information about your site is sent to Drupal.org.
That much is true whether or not you receive e-mail notifications (the second box).
...
But the link we are adding does, as you say, apply to both. Maybe the existing text should go after the first checkbox and the new text should go after the second. Or maybe that would be confusing. We need to experiment a bit.And if that seems like scope creep, then we can experiment after fixing this issue.

I have updated the issue to include a tasks to experiment with splitting out the help text, however I am open to creating a follow up. But as we are dealing with translations it is easier to manage in a single issue.
I am setting this issue back "needs work" while I take a look at the documentation and experiment with the help text split.

Replaced the summary that was used incorrectly as duplicate page status notification with an actual summary.
Made a reference to the supposed duplicate page.

Fixed the opening main paragraph as it read like it was out of context.

Hey everyone, I've updated the "Remaining Tasks" section of the issue description to provide clearer summaries and direct links to comments for better context. This should help streamline our focus and make it easier for contributors to understand and tackle the tasks at hand.

On another note, there's a mention about an unresolved aspect related to core/modules/filter/src/FilterFormatListBuilder.php attributed to @Wim-Leers. I'm having trouble finding the original discussion. Does anyone have the scoop on this? Would be great to clear that up so we're all on the same page.

I've read the page which the below claims is a duplication.  Really it is a high level overview, which doesn't go into the detail this page does.  More information is generally better than less for learners.  This page should be improved and extended, not deprecated.

I agree. This is not a duplication at all. The  Include default configuration in your Drupal module →   is, as stated, a high level overview, but specifically regarding 'including default config'.

This page provides in depth documentation as to how to create a content type by utilizing default configuration. Not at all the same things.
 

Yes there is.
I jumped the gun a little, the documentation page is a sub page of a guide and hasn't yet been reviewed by the maintainer.

Here is is for reference Drupal Needs Review Queue Initiative →

I have changed the issue status to postponed while we await that review.

Having said that, we could complete this ticket if we left out the reference to the documentation.

thursday_bw → created an issue.

Added some links to 'core gates'.

I've checked the merge request and it does exactly what we talked about – it adds a link to the installation screen that points to more info. This is a simple but useful change and everything looks good to me, code-wise.

Since I started this issue, I'm going to play it safe and not mark this as "Reviewed & Tested by the Community" myself. I think the next best step is to move it to "Needs Review" so others can take a look and share their thoughts. This way, we make sure everyone’s on board with the change before moving forward.

I've updated this issue to reflect the completion of the documentation updates discussed here. Specifically, the documentation now includes a detailed section on how selecting checkboxes during the Drupal installation process impacts the configuration of the Update Manager module.

Additionally, I've revised the "Release notes snippet" to accurately describe our enhancements. The release notes now mention not just the improvement to the description in the Drupal installation process through the addition of a helpful link but also highlight the update made to the linked documentation.

Updated the documentation to include a new section titled "Configuring Update Manager During Installation." This addition aims to provide clear guidance on how the installation choices regarding automatic updates and email notifications impact the Update Manager module's configuration. These changes were prompted by discussions and decisions in the Drupal issue Add link to Update module documentation about installer settings #3420356 → . The update includes specifics on enabling the Update Manager module through installation checkboxes and details the role of the admin user's email in receiving update notifications. The goal is to enhance understanding and ease the decision-making process for site administrators during Drupal installation, ensuring a secure and well-maintained site from the start.

I've revised the issue summary to reflect our current direction and consensus. Here are the key updates:

Proposed Resolution: Clarified that we're enhancing the "Update notifications" section with a link to detailed documentation.

Documentation Updates: Updated the section on what the linked documentation will cover.

gargsuchi → credited thursday_bw → .

Hey, thanks for your thoughts! I totally get where you're coming from – we don’t want to make the install process a headache with too much info. I just found myself scratching my head when I was trying to explain to someone new how the update thing works, and it made me think, if it's confusing for me, maybe it's confusing for others too.

I'm not trying to throw a bunch of tech jargon at folks who are just trying to get their site up and running. I just think a couple of extra words might save someone else the confusion I went through. Like, as far as I can tell this is the only check box, besides choosing a install profile that results in a module being enabled during install. It's not about the gears and bolts, but about making it crystal clear what you're getting when you tick that box.

If we're worried about crowding the page, maybe we could link to a 'What does this mean?' pop-up or a help page. This way, the info is there if you want it, but it's not in your face if you don't.

Let's try it out. If it turns out I'm the only one who was puzzled and everyone else gets it, cool, we can ditch the extra words. But maybe we'll find out that it helps a bunch of people, especially the newbies.

And I'm all for testing this to see if it really makes things better. If it does, awesome! If not, no harm done, right? We're just trying to make Drupal better for everyone, one step at a time.

I'm open to suggestions, we could document it elsewhere, I even volunteer to write it up but I don't know where to put it, and I don't like that and end user would need to go looking for it and potentially not find it, when we can lead them directly to the information.

I know from my experience, even having this conversation, I'll move on, solve numerous other problems and forget these undocumented details.

What do you say we give it a shot and see what happens?

thursday_bw → created an issue.

#117 set this to reviewed and tested by the community.
#118 re-set this to needs work with a vague bug report.
#121 spoke to the bug report and reported it as correct (meaning that 'works as expected' I believe).

Therefore setting this back to 'Reviewed and tested by the community'.

I have done some testing and can confirm that MR3556 as of 14 Jan 2024 on resolves the entiry operations problems reported on this issue, and also the username issues reported on Incorrect user linked on content page when switching users → .

OK. I have done some testing and can confirm that MR3556 as of 14 Jan 2024 on Views entity operations lack cacheability support, resulting in incorrect dropbuttons 🐛 Views entity operations lack cacheability support, resulting in incorrect dropbuttons Needs work solves the problem reported on this issue.

Closing as a duplicate Views entity operations lack cacheability support, resulting in incorrect dropbuttons 🐛 Views entity operations lack cacheability support, resulting in incorrect dropbuttons Needs work

thursday_bw → created an issue.

@jsacksick Thanks for help on this one. I went AWOL for a little while, and came back to my pleasant surprise that this is marked as great to "fixed".
Thank you :)

Here's a screencast → for you showing me installing a fresh Drupal, the relevant commerce modules, configuring the minimal settings and
showing the empty payment information pane.
I also show how adding that patch makes it disappear, and waffle quite a bit at the end LOL, my apologies ;)

This video is designed to make it VERY clear what the replication steps are and also give you the opportunity to spot if I am doing something
wrong in order to cause that empty payment information box.

Thanks for reaching out on slack earlier. No rush on this, I am able to move forward now that I understand the situation and have a patch for
that box.

If you have any questions, feel free to reach out, you're welcome to ping me on slack anytime you like.

thursday_bw → created an issue.

I am not complaining, I am reporting a bug, sorry if that puts you out. I have put in hours of my own time to do the detective work, so that YOU don't have to, you are welcome, I have created and offered a fix, so THAT you don't have to work it all out, you are double welcome.
I have gone above and beyond and you accuse me of complaining, nice work champ.
Thanks you for that, yes sarcasm is intended here.

I have not asked you for support, not once, let alone priority support. I have given a reported on my findings, I have put the work in
myself, and offered you a patch. Not responding at all is better than your response that devalues my effort and my work.

I have done all this to not put extra load on you. I have not asked any more of you than to acknowledge the bug. You gave me the brush off and bounced the ball back into my court, and so I did the work, I put in the hours to figure out the root of the issue. I reported back and you replied with the insinuation that you can't be bothered to read it. You could have just ignored it but you chose to reply and be rude instead.
I am complaining now, I am complaining about your attitude, sorry if my reporting of a bug and supplying a fix has somehow offended you.

You have given me the brush off multiple times. I have not complained, I complain now, please don't accuse me again, I have gone above and beyond for you, done the due diligence so as to not put you out and this is how you respond.

Then just read from comment #31.

I put days, i'm at about 45 hours now, of my own time into this to help resolve it and it is extremely disheartening to receive the comment you just made.

I even upload a demo that shows exactly what the issue is. Have you watched it? :(

If I repeat myself and explain once more that will just create more comments.

Please? The root issue is really straight forward, and maybe seems of low value and innocuous to you, but it triggered a cascade of misunderstanding due to ambiguous UX and going by the history I am not the first to experience it.

I really don't want to explain it again and generate even more comments.

Please read comment #31

OK doke, I have done some digging into why the payment information panel renders with empty content.
What I have ended up doing is creating this one liner patch

diff --git a/src/PluginForm/Checkout/PaymentMethodAddForm.php b/src/PluginForm/Checkout/PaymentMethodAddForm.php
index 8a5b49f..c87b3da 100644
--- a/src/PluginForm/Checkout/PaymentMethodAddForm.php
+++ b/src/PluginForm/Checkout/PaymentMethodAddForm.php
@@ -78,6 +78,7 @@ class PaymentMethodAddForm extends BasePaymentMethodAddForm {
     // We need to inject the custom card fields, only when this is the solution
     // configured.
     if (!$this->shouldInjectForm($payment_method->getPaymentGateway()->getPlugin())) {
+      $form['#access'] = FALSE;
       return $form;
     }
     /** @var \Drupal\commerce_order\Entity\OrderInterface $order */

To be honest, I do not know why Element::getVisibleChildren($form[$pane_id]);
in commerce module's modules/checkout/src/Plugin/Commerce/CheckoutFlow/CheckoutFlowWithPanesBase.php file is returning an array containing add_payment_method
I do not have my IDE setup properly, and get memory allocation errors when I dump that form. I'm hoping someone else can investigate, the form does render empty, we can see that in my previous screenshots and this patch resolves the issue.
There may be consequences that I am not aware of.

I hope this helps to clarify both what the issue is and what needs to be done to resolve it and gives you a large clue as to why that payment information panel renders empty. I have put in a lot of time to try and move this along and relieve the workload.

I realise there is a lot to get through on this, and I have been going backwards and forwards doing detective work to identify what is going on.
I have made mistakes here and there along the way as there are so many moving parts and variables that alter behavior.

This comment is to highlight what I believe is the root cause of the complexity

This screen is easily reproducible. Just install Drupal with the standard profile, then install commerce_paypal module, commerce_cart, commerce_product and commerce_checkout modules.

Create a store.

Create a payment gateway and uncheck the box for showing smart payment buttons on the cart page.

Add a product, then add that product to you cart.

View your cart, and you will see a page like this:

Notice how the 'payment information' pane is empty? That is the problem here. That is the issue. That is what starts a cascade of confusion.

As a site builder, not a developer, it is a perfectly reasonable conclusion at this point to say "Well, I obviously do not have any payment information, I will go to the checkout flow and disable that panel from the review pane", but doing breaks the entire checkout flow, it silently breaks it, no warnings, no errors it just results in a checkout flow that does not function.

My patch supplied earlier is a hack to attempt to resolve this, but it only half works, it allows the smart buttons to be added to the review page but the order never goes through.

It does happen that if one clicks "continue to review" the payment information is rendered again, on this page however it does indeed show 'paypal'. It shows but I assert that this is redundant and confusing at this point, the user did not select paypal because on the previous page the payment information was blank.

If you then click 'edit' on the payment information panel you are taken back to the 'order information' page and this time it does render the 'payment method' box with a single radio box labelled 'paypal', and that is also nonsensical, why have an unalterable radio button to select the only possibly available selection.

So, two recommendations:

1) Resolve the issue with the payment information box being blank when first viewing the order information page.
** In an incognito window it seems that it is only the VERY first time you view the page that this happens. If it does render try clearing the cookies perhaps? I am using an incognito window, closing that window and opening it again will cause the payment information to become blank once more.

2) Implement a warning during checkout on the 'order information' page, or perhaps write the log a message to indicate that the the payment information panel as been disabled and that it needs to be enabled. It is perfectly reasonable for a site builder to want to hide that and modify the checkout flow to do so. This is mitigated however by the fact that if the payment information renders correctly as resolved by recommendation 1 then it is far less likely for a site builder to have disabled the payment information pane.

OK. now that I have a patch, and given that out of the box this displays a broken payment information panel, I'm marking this back to critical.
Along with the patch the site builder needs to know to disable the payment information panel or it displays in a broken manner..
we also need to figure out why that panel displays in a broken manner, and we need to discuss how to handle it appropriately, it makes no sense to offer a form item to choose a payment method when there is only one payment method to choose from.
A module shouldn't require one to add CSS or use an alter hook to hide things (eg the payment information panel), it should not result in confusing and misleading form options displaying in Drupal's standard theme with the most basic and essential settings, that is not a support issue, it is a reproducible bug.

Dang, I clearly patched that against the wrong version of code..
It's almost midnight and I am knackered, here is a re-roll →

I whipped up a patch → that implements a way for this module to handle that case of the payment info panel being disabled on the checkout flow when there is only one enabled payment gateway that is one of the paypal payment gateway plugin types.

It will need work, I did it in quite a rush and more as a proof of concept than anything else.
I only performed a very quick test.

I found this 'outdated' issue on the commerce module: https://www.drupal.org/project/commerce/issues/1854062 ✨ hide payment method selection where there is only one payment type Closed: outdated
It is closed as 'fixed in commerce 2.x' but there is no link to the issue or commit where it was fixed :(

But it sheds some light on the situation

Closing this out as I wouldn't make such a change in the 1.x branch now but we did fix this in 2.x. : )

Huh?

This clearly is not fixed, I've come to this issue after hours of detective work for an issue on commerce_paypal module: Paypal smart buttons showing on cart page not review or payment page 💬 Paypal smart buttons showing on cart page not review or payment page Active

Expecting a sitebuilder to add CSS to their theme to get a module to work with a single payment gateway out of the box is just not the correct solution here, in my humble opinion, the fact that I spent days pulling my hair out to wind up here on this issue is a testament to that.

"when there is only one payment method available, the radio for selection shouldn't appear." 100% when there is only one payment method available the selection for it should not appear, that's just, is that debatable? how so?

Perhaps in the case of commerce_paypal it is the responsibility of commerce_paypal to take care of this issue? I'm not sure.

What do we do to resolve this issue? should the commerce module hide the payment information panel if only one payment option is available? that's confusing too because it makes the 'payment inforamation' pane being enabled in the checkout flow confusing as heck if it doesnt' actually appear in this context, it would be enabled but not visible.

I think it does make sense that the sitebuilder could hide the payment information panel from the checkout flow via config, doing so causes breakage in the commerce_paypal module, so having said that I am thinking it is commerce_paypal's responsibility to deal with this scenario
but It's worth communicating it.

Is this perhaps more of an issue with the commerce module itself?
Is commerce module causing this issue of the empty payment information when only one payment gateway exists?
It definitely is incorrect to display a form (and often empty form) to select the only available payment gateway.

OH.. so now I understand that code: in commerce_paypal_form_commerce_checkout_flow_alter()

  if ($order->get('payment_gateway')->isEmpty() ||
    !$order->get('payment_gateway')->entity ||
    $order->get('checkout_flow')->target_id === 'paypal_checkout') {
    return; // Is returning here.
  }

$order->get('payment_gateway')->isEmpty() is TRUE because having hidden the payment information, the payment gateway was not able to be chosen by the user and therefore was not set.
!$order->get('payment_gateway')->entity I imagine a very similar issue, we havent' chosen a gateway so no entity could be set on the payment_gateway.

My earlier testing showed that $order->get('checkout_flow')->target_id === 'paypal_checkout' evaluated to FALSE, but that doesn't make sense, target_id should still be 'default' correct? I can double check that I guess.

So, I imagine this code needs to be made more robust if there is only one payment gateway existing and it is a paypal gateway, then the system needs to auto assign paypal as the payment gateway and thus allow the site builder to hide the payment information.

Ignore the section where I submitted the order and confused myself lol.
But yes, why is the 'payment information' section empty/why does it only show paypal when clicking on 'edit' on it one the review page and why do the paypal buttons disappear on the review page when the payment information is disabled, but only for anonymous users, it does display for admin users?

OK. I worked am able to replicate it now.

I was disabling the payment information item from the checkout flow because it seems surpurfluous.
If you view the demo I uploaded you can see that when you first view that as an anonymous user it is empty, it's just an empty fieldset.
and then later if you come back and edit it it has a radio box that just says 'paypal' and it makes no sense to have a single radio
button with only one option.. So I disabled the payment information, I don't want my user to see it as it is confusing.

It is disabling that that causes the paypal buttons to not display.
So perhaps this issue needs to be modified from "Paypal smart buttons showing on cart page not review or payment page" to,
"how to hide the the redundant 'payment information' item from the 'order information' pane?

I'll change this back from a bug to a support request, but it's debatable because the payment information showing as empty/with only paypal when you got back and edit it is odd behaviour.

Demo screencast of payment information pane issue →

OK.. I did a recording of configuring it on a fresh install, again and it bloody well worked.. I don't know what to tell you :(

The one thing I did differently was not attempt to purchase the same product as admin before trying as guest.

I am changing this to a bug report, it's not a support request, unless you can tell me what configuration I have wrong to create this situation.

I am supplying debugging data from a hook at this point so as to describe the bug.
Replication steps are pretty straight forward:
enable commerce_paypal, commerce_product, commerce_cart and commerce_checkout.

drush en commerce_product commerce_cart commerce_checkout commerce_paypal -y

Add a store:

Add a payment gateway.

Add a product and add a price to it's variation.

open a private browser window so as to be a guest.
browse to /product/1

click 'add to cart'

browse to /cart

click 'checkout'

click 'continue as guest':

enter contact email and click 'continue to review':

... Oh man... what?!?!!

OK.. as I was taking all these screenshots, I removed my product and added it again, I also went to the review page and then left it again to go and take a screenshot of the order information page and when I returned to screen shot the review page the paypal buttons appear now.

Similar to other night, "oh, it's workign now".. I have not changed any of my configuration.. we have screenshot evidence of it not showing these buttons.. I do not know what to tell you other than, it works sometimes, others it doesn't.

Can you please test this on a fresh install, freshly configured and add your first product?

I have no option I guess but to keep testing. I have seen this behaviour twice now.
I am trying to give you reproducible steps but it is difficult to document as the behaviour is PROVABLY inconsistent, as per my screenshots and the above debugging information.

I will yet another fresh install of drupal, configure this all once more, and see if it is only happening on the first attempt to go through the checkout process.

Tell you what, I may record the entire process, (I already have but I will do it fresh because it's a shit recording) and upload that.

Apologies for the confusion of putting some of the history on that other ticket, here are the screenshots of the buttons displaying as a logged in user, and not as an anonymous user"

OK. to help avoid confusion, the other issue referred to here is: https://www.drupal.org/project/commerce_paypal/issues/3331179 🐛 Paypal Buttons Don't Appear on Drupal 10 Fixed (Paypal Buttons Don't Appear on Drupal 10)

My final comment ( https://www.drupal.org/project/commerce_paypal/issues/3331179#comment-15... 🐛 Paypal Buttons Don't Appear on Drupal 10 Fixed ) at 3am on that issue after many hours of bashing my head against a brick wall I wrote "Hmm. I have it working now.. I was brain farting at the end there (it is 2:53 am lol)...I wasn't clicking all the way through to the review page and was looking at order information.". That was a few days ago. I have created a fresh install of Drupal and configured PayPal once more and I am back in the same situation, and I am definitely looking at the review page this time, the smart buttons do not display on the review page. I have no idea what caused them to magically show up at 3am in the morning last time.

If you're comfortable debugging... You can try following the logic from commerce_paypal_form_commerce_checkout_flow_alter() (the buttons are injected from there).

I have done some more debugging as requested. The offending code is the following if statement, which I have annotated with some comments:

/**
 * Implements hook_form_BASE_FORM_ID_alter() for commerce_checkout_flow.
 */
function commerce_paypal_form_commerce_checkout_flow_alter(&$form, FormStateInterface $form_state) {
...
  if ($order->get('payment_gateway')->isEmpty() ||
    !$order->get('payment_gateway')->entity ||
    $order->get('checkout_flow')->target_id === 'paypal_checkout') {
    return; // Is returning here.
    // Both $order->get('payment_gateway')->isEmpty() and !$order->get('payment_gateway')->entity are TRUE;
  }
...
  // Inject the Smart payment buttons on the review page.
  // Skip injecting the smart payment buttons if the order total is zero or
  // negative.
  echo "Inject smart payment buttons on the review page\n";
  if (!$order->getTotalPrice() || !$order->getTotalPrice()->isPositive()) {
    echo "returning 4<br />\n";
    return;
  }

  if (!$payment_gateway_plugin instanceof CheckoutInterface ||
    $payment_gateway_plugin->getPaymentSolution() !== 'smart_payment_buttons') {
    echo "returning 5<br />\n";
    return;
  }
  /** @var \Drupal\commerce_paypal\SmartPaymentButtonsBuilderInterface $builder */
  $builder = \Drupal::service('commerce_paypal.smart_payment_buttons_builder');
  $form['paypal_smart_payment_buttons'] = $builder->build($order, $payment_gateway, TRUE);
  $form['actions']['#access'] = FALSE;
  // Put back the "go back" link.
  if (isset($form['actions']['next']['#suffix'])) {
    $form['paypal_smart_payment_buttons']['#suffix'] = $form['actions']['next']['#suffix'];
  }
}

I do not know the commerce API very well, actually I don't know it at all, consider me a site builder at this point.
I have no idea wh payment_gatway would be empty on this order entity, heck, we haven't created an order yet, we haven't completed the checkout or the payment so there can't be an order. I don't know why !$order->get('payment_gateway')->entity is empty.

Remember this is only as an anonymous user, the buttons show when I get to the review page on a checkout when logged in as admin.

Hmm. I have it working now.. I was brain farting at the end there (it is 2:53 am lol).

I wasn't clicking all the way through to the review page and was looking at order information.
so perhaps my reinstall resolved it. My previous setup was a database that had version 1.0 and had been upgraded to 1.4.. maybe that was it. I don't know.. It is 3am, I am going to be and will revisit this tomorrow and see if it still works.

This is all on a stock standard drupal and I need to transfer to the site I am building, I have learned heaps, thanks for you prompt support.

I have done some debugging.

In this file: commerce_paypal/src/PluginForm/Checkout/PaymentMethodAddForm.php
In the shouldInjectForm() method, `$plugin->getPaymentSolution() ` is returning `smart_payment_buttons` not `custom_card_fields`.

Does that give you a clue?

I did a full reinstall of the standard Drupal profile and reenabled the relevant commerce modules and configured it again
and get teh exact same behavior.

```
drush en commerce_paypal commerce_product commerce_checkout -y
```

I created a store.
I created a payment gateway with all default values apart from the name, the sandbox client id and secret, and disabling the show smart buttons on cart checkbox.
I created a product and then added that product to my cart as admin and went through the checkout process up until I the review page where I saw the smart buttons show.

I repeated that step as an anonymous user and got the same result as described above, not smart buttons on the review page.

I have checked the view source of the page as both admin and anonymous and the script tag does not show in the source for anonymous users.

The smart buttons do appear on the cart page for anonymous users when I enable them.

Network log FYI, nothing much to see here either.
I can see that 'once' is loaded.

First thing I did was look for console errors, there was nothing to see there.
I haven't set any conditions on my payment gateway

Here you can see as a logged in user the relevant JS files are loaded.

Here as an anonymous user, they are not.

I realise this issue is closed and fixed, but I am seeing this exact issue.
The buttons show for a logged in user, but not anonymous :/
I have the latest release 1.4 from 18th Jan installed.. hmm.

When I get my head clear.. This is working a treat except that the paypal buttons are now not appearing on the review page when viewing as an anonymous user.. and I see an issue open with a fix for that exact problem :(
Thanks for your help, I'll switch over to that issue to continue to comment.

OK.. I changed my order type to use the default checkout flow instead of the paypal checkout flow.. that is very counter intuitive but it works now. Well kind of, I don't want the 'payment information' screen, all it offers is a radio button to select paypal, which is the only payment gateway configured so it is redundant.
I am configuration this as a payment gateway for a digital download and I have no need to collect a shipping address.

I will try now with my own checkout flow as I was going to before I tried with the default one.

Not at any time did it occur to me that using the paypal checkout flow was the wrong way to get paypal to work in the checkout flow.. seemingly obvious why that is confusing isn't it?

I hindsight I now understand what the documentation means at https://www.drupal.org/docs/8/modules/commerce-paypal/paypal-commerce-pl... →
I missinterpreted what "payment is initiated on the cart page" means. :(
"You will also want to verify that the "PayPal Checkout" checkout flow exists in your configuration. If you're working with a fresh install of the Commerce PayPal module, it should be installed automatically. This checkout flow is automatically used when the payment is initiated from the cart page via the Smart Payment Buttons. In this scenario, you want the checkout steps to be reduced to the minimum. "

By "payment initiated on the cart page" you mean the user utilised one of the smart buttons on the cart page.. I have effectively conflated the idea of 'checking out' and 'initiating payment' as the same action, so I interpreted 'clicking checkout' as 'initiating payment' and took this to mean that my checkout process had to use the paypal checkout flow. Particular since one imagines that the checkout flow applies to checking out, not to bypassing the checkout.

Do you see how this doc is confusing?

I have been at this for hours and hours and it is 11:41pm now, my brain is mush. I'll attempt to better word the docs when I have had some sleep.

thanks for you response, I was able to tease out the information I needed from that.

I saw on one of these issues someone pointing out that having smart buttons on the checkout AND A checkout button is confusing to the user. I concur with this too. Why have both? I do not understand.
I'm not sure what the purpose and usecase of the smart buttons on the cart page is, especially since one can not disable or remove the checkout button without hacking code.

Ok.. that has cleared things up heaps.. I still have some configuring to do to get this to work, but wow, actually seeing paypal in the checkout process is a win. thank you again.

But first, I need to reinstall the latest release because I downgraded 1.0 hoping the issue would not have been introduced in the older version. :/

jsacksick, I'm sorry, I dont' understand what you are saying.
what "shortcut" flow?
The fact remains that the smart buttons will not display in the checkout flow, I have been trying different configurations and reading documentation, clearing caches, installing older version etc for days now.

"The idea being that when the payment is initiated from the cart page," what payment is intiated from the cart page? sorry, what do you mean?

"If the payment is not initiated from the cart page," where else would it be initiated from?

"If the payment is not initiated from the cart page, the checkout flow configured for your order type will be used." my order type has the paypal checkout flow configured as it's order type.

Are you saying I should create my own checkout flow and set my order type to use that and also disabled the smart buttons on the cart?
maybe, I have tried so many combinations of configuration I can't remember what I have tried and what I haven't.. are you sure they work at all? I'll try creating my own checkout flow and adding the paypal payment process to that and set my order type to user that checkout flow.. if that is what you mean.

I am seeing this exact same issue, and it is also reported here: https://www.drupal.org/project/commerce_paypal/issues/3380733 💬 Paypal smart buttons showing on cart page not review or payment page Active

4 months and no response on that other issue, and 6 on this one.

I have been configuring and working with this module for about 3 days now to try and get it to work and am now finding both these issues.

I downgraded the module just now to version 1.0 and the smart buttons do not show on the cart on that version either.

This is a critical issue, if the checkout flow does not integrate paypal, then what's the point of the module, that is it's usecase.

I'll keep digging as I need it to work, but I have spent days on this already.

I am experiencing this too. I am not getting the smart buttons on the checkout flow.
I can see them on the cart page if I enable the checkout box to show them on the cart on the payment gateway settings.
but the checkout flow never shows them, no matter what I do.

I am trying to setup a digital download and do not want my drupal site to collect the address information.

You stated above that the payment information must appear before the review pane, however this statement contradicts the module's default configuration. Upload installing commerce_paypal my paypal checkout flow exists, and it does not have payment information set in the Order inforamtion section, or the review pane. If I put it there in then asks for address information, even though I have 'collect order information' disabled on the paypal payment gateway settings.

thursday_bw → created an issue.

"IMO it would also be fair to close the issue since the consequences appear to be not that significant. This issue has not been identified to the security team as a root cause of a site takeover." seems fair to me.
Should we just do it?

update issue and add recommendations with questions for the security team.

"See #3227354: Add support for ckeditor5-autoformat for Drupal 10 and CKEditor5. This is included in core since Drupal 10.1.0." I just came to say the same thing.

Here you can see on drupal 10 that when I installed you module with composer, it also installed the ckeditor contrib module.

bevan@workhorse drupal_blog]$ git diff composer.lock 
diff --git a/composer.lock b/composer.lock
index b6e86c9..6504d70 100644
--- a/composer.lock
+++ b/composer.lock
@@ -4,7 +4,7 @@
         "Read more about it at https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies",
         "This file is @generated automatically"
     ],
-    "content-hash": "e1cf633462082db0efe8c3151e1ed608",
+    "content-hash": "c6a676cebff0d8376b417b5103868afc",
     "packages": [
         {
             "name": "asm89/stack-cors",
@@ -1140,6 +1140,146 @@
             ],
             "time": "2022-12-14T08:49:07+00:00"
         },
+        {
+            "name": "drupal/ckeditor",
+            "version": "1.0.2",
+            "source": {
+                "type": "git",
+                "url": "https://git.drupalcode.org/project/ckeditor.git",
+                "reference": "1.0.2"
+            },
+            "dist": {
+                "type": "zip",
+                "url": "https://ftp.drupal.org/files/projects/ckeditor-1.0.2.zip",
+                "reference": "1.0.2",
+                "shasum": "fec2ca9ad852a00c7b9584cb6040dc860364c481"
+            },
+            "require": {
+                "drupal/core": "^9.4 || ^10"

For even more confirmation:

ls html/modules/contrib/ckeditor
ckeditor.admin.inc  ckeditor.api.php  ckeditor.info.yml  ckeditor.libraries.yml  ckeditor.module  ckeditor.post_update.php  ckeditor.services.yml  config  css  js  LICENSE.txt  src  templates  tests  vendor

I'm not sure why it does that, but it appears to create conflicts on the config page where ckeditor and ckeditor 5 are both listed and they both throws errors on the page "CKEditor 5 only works with HTML-based text formats. The "Markdown" (markdown) filter implies this text format is not HTML anymore."

Yeah,, it's not working on Drupal 10.

"I think this ticket should be closed - this issue fixed in the latest Drupal versions." I don't see any evidence or even suggestion of this having been fixed, and since i'm looking at it on Drupal 10 going "this looks exactly like my issue", I am going to re-open it.

Rather than re-open this ticket, I will mark this related issue, I think they are duplicates: https://www.drupal.org/project/drupal/issues/2998728 🐛 Reverse proxy settings for multisite cannot work Needs work

The example configuration was not clear on the naming requirements for the config file name, nor that a section of the configuration
must match the ID string of the config object.
The existing example also had an ID that was the same as the plugin ID which obscured even further the relationship between the file
name and the id and also obscured the ID: and Plugin  ID: do not need to match.

thursday_bw → created an issue.

Luke Nuke, there is a work around for exporting layouts that works now, without any patch by taking advantage of layout builder library module. https://www.drupal.org/project/layout_library →

With this you can create a layout in the library, and then instead of adding a layout override on a node, you tell that node to use the layout from the library.. and then it all exports nicely.

OK.. Work around.

I'm uploading this patch but I do not recommend that it be accepted into core.
It's just here for you to apply to D8.7 if you so choose as a work around.

If you apply patch 2942975-24.patch →
along with 2942975-52.patch →

You will be able to export the layout using
default content deploy →

Due to https://www.drupal.org/project/drupal/issues/3028301 → restricting exposure of layouts, I don't know yet what a correct solution to this
would be.

If i'm understanding all this correctly,
layouts aren't exposed to REST and other API's in drupal 8.7.* due to https://www.drupal.org/project/drupal/issues/3028301 → which in turn means, default_content_deploy doesn't export it either. Even with the patches on the issue this comment refers to being applied.

Can anyone thing of a work around, even if temporally?

Like gundose stated.

The patches on this page don't work with 8.7.

I have applied the patch in #24 → cleanly, however there is no layout in the exported landing page.