Chris

Sorry, but the problem’s not at this end: Enlighter is not semantically marking up code as code, it’s just wrapping it in <div> tags so WordPress (and thus this plugin, which uses WordPress filters) has no way of knowing that it’s actually code.

WP-Syntax is an alternative plugin that marks up code properly, I’ve been using it for years.

• This reply was modified 7 months, 3 weeks ago by Chris.
• This reply was modified 7 months, 3 weeks ago by Chris.

I’ve bodged in the one line fix to my site for the moment, can chuck it in a PR if you like?

Does this mean the plugin should also extend Walker_Comment->comment() to catch themes that don’t declare html5 support?

• This reply was modified 8 months, 2 weeks ago by Chris.

Can confirm that changing Comment_Walker->html5_comment() to call parent::html5_comment() instead of parent::comment() fixes it.

Can also confirm I feel a bit stupid for not spotting it.

• This reply was modified 8 months, 2 weeks ago by Chris. Reason: formatting

Manually deleting and reuploading isn’t remotely feasible for a site that’s been around for any length of time, a media library could extend to hundreds or thousands of images.

That nailed it, nice one.

It’s going to be something to do with the host’s cache, because I’ve already tried disabling the cache plugin I found.

Per their docs here:

Caching cannot be fully disabled on your website, or on your website’s homepage, as this will negatively impact your site’s performance.

The donation form is loaded into an iframe by a button appearing in the sitewide header. Apparently I can create exclusions by path, argument or cookie, do you have a list of what I should exclude to get this working? Is the list in your cache FAQ comprehensive?

Hi Rick,

I discovered as I was working through the problem that the plugin wasn’t as up to date as I thought. Happy to mark this one resolved, but I’m still having the problem I described in my update to this thread.

Update: turns out the install was hiding update notifications. Have now updated to v2.21.4 and it’s no longer throwing a fatal error, but the confirmation page is still not displaying when a logged out user makes a donation. When there’s a logged in WP user the confirmation page displays correctly.

Disabling cache makes no difference, GiveWP site status raises no issues.

The only entry in the WP debug log related to the plugin is now:

[22-Jul-2022 17:17:26 UTC] PHP Notice:  Undefined index: donor_id in /nas/content/live/purposefounstg/wp-content/plugins/give/includes/donors/actions.php on line 25

• This reply was modified 2 years, 4 months ago by Chris.

Update: reverting to PHP7.4 solves the issue in the short term, but that’s not sustainable.

Should be fixed now, thanks for your patience.

Good catch. Latest release should fix that, sorry for the delay.

Sorry about that. I’ve done a quick and dirty fix but I might have to free up some time for more comprehensive refactoring in the near future.

Thanks for bringing that to my attention. I’ve pushed a release (2.0.5) that should resolve the problem.

If you do decide to fix it this should do the trick on line 34:

if ( ! $( app.hash ) )

change to:

if ( ! $( app.hash ) || location.pathname.replace(/^\//,'') != this.pathname.replace(/^\//,'') )

I’m afraid I’ve already removed the plugin, it was causing issues on a live site.

Easy enough to reproduce though, create two pages, each with #hash1, #hash2 and #hash3 and populate a menu with absolute URLs to them. The problem is on lines 30-39 of assets/js/hash-link-scroll-offset.js – a link on /page1 to /page2#hash1 will scroll to /page1#hash1 if #hash1 exists on /page1.

Should be able to fix it by comparing this.pathname with location.pathname before calling app.scrollToHash.

• This reply was modified 6 years, 3 months ago by Chris. Reason: Clarity