bobdobbs

Hi again Stephanie.

I loaded the page again, in incognito mode in chrome.
This time the spinner appeared but didn’t dissapear. A message in console seemed to show that the server had thrown a 500 error.

Looking at the server logs, it looked like a function associated with the classic donation form template – the one I remember selecting – was expecting a parameter that wasn’t being passed in.

This somewhat resembled the js error – also seemingly associated with the classic template.

So I went back to look at the form settings…

… and the form didn’t exist.

It looks like at some point I trashed the form for some reason and forgot about it.

The page still had the shortcode for the form – but no form existed.

After recreating the form and re-inserting the new shortcode, everything works just fine.

Hi Stephanie.

The optimisation plugin is only triggered when images are uploaded to the media library, afaict. But just in case, I disabled it – along with all other plugins that aren’t GiveWP.

The error still persists.

I switched to the twentytwentytwo theme. The error still persists.

I then noticed that there is an update to GiveWP, so I updated. The error still occurs.

Home URL: https://***.localdev
Site URL: https://***.localdev
WP Version: 6.2
WP Multisite: –
WP Memory Limit: 512 MB
WP Debug Mode: –
WP Cron:
Language: en_US
Permalink Structure: /%postname%/
Show on Front: page
Page on Front: *** (#5)
Page for Posts: Unset
Table Prefix: wp_
Table Prefix Length: 3
Table Prefix Status: Acceptable
Admin AJAX: Accessible
Registered Post Statuses: publish, future, draft, pending, private, trash, auto-draft, inherit, request-pending, request-confirmed, request-failed, request-completed, acf-disabled, refunded, failed, revoked, cancelled, abandoned, processing, preapproval
Server Environment
Hosting Provider: DBH: localhost, SRV: ***
TLS Connection: Connection uses TLS 1.3
TLS Rating: Probably Okay
Server Info: Apache/2.4.52 (Ubuntu)
PHP Version: 8.1.18
PHP Post Max Size: 5 GB
PHP Time Limit: 30
PHP Max Input Vars: 1000
PHP Max Upload Size: 5 GB
cURL Version: 7.81.0, OpenSSL/3.0.2
SUHOSIN Installed: –
Default Timezone is UTC:
fsockopen/cURL:
SoapClient:
DOMDocument:
gzip:
GD Graphics Library:
Multibyte String:
Remote Post:
Remote Get:
GiveWP Configuration
GiveWP Version: 2.26.0
GiveWP Cache: Enabled
Database Updates: All DB Updates Completed.
Database Migrations: All Database Migrations Completed.
Database Tables:
wp_give_donors
wp_give_donormeta
wp_give_comments
wp_give_commentmeta
wp_give_sessions
wp_give_formmeta
wp_give_sequential_ordering
wp_give_donationmeta
wp_give_revenue
wp_give_migrations
wp_give_log
GiveWP Cache: Enabled
GiveWP Emails:
New Donation
Donation Receipt
Donation Processing Receipt
New Offline Donation
Offline Donation Instructions
New User Registration
User Registration Information
Donation Note
Email access
Upgraded From: –
Test Mode: Enabled
Currency Code: NZD
Currency Position: Before
Decimal Separator: .
Thousands Separator: ,
Success Page: https://***/donation-confirmation/
Failure Page: https://***/donation-failed/
Donation History Page: https://***/donor-dashboard/
GiveWP Forms Slug: /donations/
Enabled Payment Gateways: Test Donation, Offline Donation
Default Payment Gateway: Test Donation
PayPal IPN Notifications: N/A
Donor Email Access: Enabled
Stripe Webhook Notifications: N/A
Active GiveWP Add-ons
Other Active Plugins
Admin Columns Pro by AdminColumns.com – 6.1.3
Advanced Custom Fields PRO by WP Engine – 6.1.4
Advanced Themer for Bricks by Maxime Beguin – 1.0.4
BricksExtras by BricksExtras – 1.2.5
Classic Editor by WordPress Contributors – 1.6.3
Custom Body Class by Andrei Lupu – 0.7.3
Custom Fonts by Brainstorm Force – 1.3.7
Duplicate Page and Post by Arjun Thakur – 2.9.2
EWWW Image Optimizer by Exactly WWW – 6.9.3
SEOPress by The SEO Guys at SEOPress – 6.5.0.3
Simple Page Ordering by 10up – 2.5.0
Social Warfare by Warfare Plugins – 4.4.1
Social Warfare - Pro by Warfare Plugins – 4.3.0
Ultimate Dashboard by David Vongries – 3.7.4
Ultimate Dashboard PRO by David Vongries – 3.7.0.1
UpdraftPlus - Backup/Restore by UpdraftPlus.Com, DavidAnderson – 2.23.3.26
WPForms by WPForms – 1.8.1.2
WPForms Conversational Forms by WPForms – 1.10.0
WPForms MailerLite by WPForms – 1.0.1
WPForms Stripe by WPForms – 2.11.0
WP Mail SMTP by WPForms – 3.7.0
Inactive Plugins
Give - Recurring Donations by GiveWP – 2.3.1
Give - Stripe Gateway by GiveWP – 2.5.0
Theme
Name: ****
Version: 0.1.0
Author URL:
Child Theme: Yes
Parent Theme Name: Bricks
Parent Theme Version: 1.7.3
Parent Theme Author URL: https://bricksbuilder.io/

• This reply was modified 1 year, 11 months ago by bobdobbs.

Thank you!

That should have been obvious but I didn’t think of it.

Hi Cory.

I’m getting the same error message. I’m running PHP Version 7.4.8.

Just like OP, I’m getting a message from Duplicator itself telling me to upgrade, even though I’m running a sufficiently recent version of PHP.

I disagree with your assessment that this message is from WordPress.
I’m seeing it in a message from Duplicator itself.

It’s a Duplicator issue: Duplicator can see that I’m running a recent version of PHP, reports the version number accurately, but also reports that the version is older than 5.2.9.

Hey Justin!

I just did a quick test with the latest versions or BB, a base roots install, and my own starter theme based on roots.

All is good. BB works in these two themes.

I probably messed up with my initial test anyway. I might have been testing on pages that didn’t have an area generated by the_content().

my bad!

Hi Justin!

Just to let you know that I’m busy for the day. However, I’ll do a little more testing and reply to this thread as soon as I can.

Thanks!

thanks ??

Hey Darren. Hope your weekend is going well.

I’ve built a test case here:
https://dev4.sunil.co.nz/blog

This is what the template looks like: https://gist.github.com/sunilw/68107641d79578f5074f

(Nevermind the awkward positioning of the ‘load more’ button.)

I may have found a workaround: putting the ‘load more’ button outside of #masonry-wrapper.
This workaround would require a little hackery, but it could be the beginning of a solution.

Hey guys. Thanks for responding Cory!

I’m afraid I can’t provide any more detail: I abandoned this migration a while ago. (I wasn’t dealing with a production site).

In future, if I this this issue, I’ll make sure to test out the dev version of the plugin.

I’m logged in with the admin account.

Setting ‘sitewide’ to YES also solves this problem for me.

The setting doesn’t really matter to me. But now I’m wondering why the setting exists, if the plugin doesn’t work with one of it’s options.

Nearly a year later, and this problem still exists.

The templating system is still completely absurd. So it needs good documentaton.

But the documentation offered by woocommerce is still absolute rubbish.

Once I’ve done my current project, I’m never going near the pile of rubbish that is woocommerce again.

There is absolutely no reason for their templating system to be so difficult. I’d recommend developers stay away from this dreck.

More information:

I looked at the plugin file. The notice says that “is_feed()” is being incorrectly, so I looked at the source of wp-minify.php.

line 67 has this:

if (!is_admin() && !is_feed() && !defined(‘XMLRPC_REQUEST’)) {…}

I used another browser, from which I’m not logged on into the site. As I figured, the notice doesn’t show: I’m not hitting the “is_admin()” condition.

However, there are no error reported, and the files are still not being delivered minified.

I went one better, and deleted all plugins except wp-minify.

I’m still getting the same result.

The notice I’m getting is:

Notice: is_feed was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.) in /var/www/test/web/wp-includes/functions.php on line 3012