If one puts a CiviCRM short code for a contribution page on the home page of their site like in the screenshot below (no basepage just wpv560.localhost):
When creating a contribution thru this form, the user can submit the form, confirm the contribution on the confirmation form and the contribution does go thru and get recorded to civi HOWEVER, instead of being taken to the Thank you page, the user receives a "Too Many Redirects" error like below:
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
alicefruminchanged title from A civicrm shortcode for a contribution page on the homepage results in a "Too many redirects" error to A civicrm shortcode for a contribution page on the homepage results in a "Too many redirects" error instead of the thank you page
changed title from A civicrm shortcode for a contribution page on the homepage results in a "Too many redirects" error to A civicrm shortcode for a contribution page on the homepage results in a "Too many redirects" error instead of the thank you page
I am not sure. I've never added a contrib form to the home page, nor is this use case in our test grid.
@haystack is this a limitation of the way the shortcodes are implemented? IIRC the shortcodes work only on content and only display the form if there is a single shortcode . Multiple shortcodes behave differently and show links to the pages.
Thinking out loud:
If the forms are called natively ie: http://wpcvmaster.test/civicrm?page=CiviCRM&q=civicrm/contribute/transact&reset=1&id=1 then the base page is used on the initial form and all subsequent pages civicrm.
If a shortcode is added ie: http://wpcvmaster.test/donate-now/ then donate-now is used on all subsequent pages such as http://wpcvmaster.test/donate-now/?page=CiviCRM&q=civicrm/contribute/transact&_qf_ThankYou_display=true&qfKey=75af427cc88479a118a4f0c64e51afc0_678
I would expect that the redirect to the Thank You Page would fail. @alicefrumin do you recall this working in a prior version? I tested back to 5.3.2 and get the same behavior. @eileen if you've fixed it then I know it's possible but we'll have to take a look.
@kcristiano I've never seen this work and had not tried it until a client requested it recently (I think they were on 5.5 then I tested it on 5.6 and 5.8beta). I think you are right that it has to do with the lack of a basepage, and that it makes sense that it breaks. It also seems like an easy mistake for an unsupervised organization to make.
We'll need to rework that a bit, but I understand someone could think that a shortcode on the front page would work.
What do you think?
Just a side note - if you create a post and have the latest posts display on the home page the page works. It is specifically when a 'Front Page' is set in the Reading Settings and is_front_page() returns true that we have the issue.
@alicefrumin I can replicate your symptoms. What's actually going on is related to the fact that CiviCRM does not generate valid URLs when CIVICRM_CLEANURL is off. I mean URLs of the form:
What happens on the home page is that this URL is caught by redirect_canonical on the template_redirect hook and redirected to a rebuilt URL of the form where q is URLencoded:
but, crucially, not before CiviCRM has sent the confirmation email and cleared the session. This causes the next page load to trigger invalidKeyRedirect and thus the infinite redirect that we're seeing. This does not happen on any other page because of the logic in redirect_canonical:
diff --git a/includes/civicrm.shortcodes.php b/includes/civicrm.shortcodes.phpindex ea56e41..1797a86 100644--- a/includes/civicrm.shortcodes.php+++ b/includes/civicrm.shortcodes.php@@ -175,8 +175,8 @@ class CiviCRM_For_WordPress_Shortcodes { return; }- // How should we handle multiple shortcodes?- if ( $shortcodes_present > 1 ) {+ // How should we handle multiple shortcodes? Also do not render on home page or front page+ if ( $shortcodes_present > 1 || is_front_page() || is_home() ) { // Add CSS resources for front end add_action( 'wp_enqueue_scripts', array( $this->civi, 'front_end_css_load' ), 100 );
Converts the content on the Front page from the actual Form to an excerpt and link to the form
Not what they would desire, but it will work.
Would like to have @haystack chime in before we decide what best course is.
@haystack I just tried the quick fix and am still getting redirects. Your way makes perfect sense, I am thinking the correct path here is not a quick fix, but to wait for Clean URLs?
And this code exists from the start of the submission process so that the "Confirm" form's <form action="SUBMITURL"> is URLencoded? That's the crucial point - if that URL is not URLencoded, then the redirect is definitely triggered in redirect_canonical and not elsewhere.
@kcristiano FWIW, I'm pretty sure the redirect you're seeing with just the rawurlencode fix is due to the inclusion of the $wpPageParam variable in the URL, so that page_id=123 (or whatever your homepage page_id is) is included in the URL. Doing this causes WordPress to redirect to the page with the ID given in the URL, regardless of whether CiviCRM is present or not. My modified function in the Gist above only includes that when the permalink_structure option is not set.
@kcristiano I think your suggestion of handling a shortcode on the front page the way multiple shortcodes on the same page works is great or if @haystack has a fix that makes it so the shortcode works on the frontpage even better.. I am also good with waiting for clean URLs. Hopefully, if someone else has this problem they will find this documentation :).
Additionally, I am happy to test a pr if someone puts one together.