crdunst

I’m thankful to have found this thread. We’ve also had the same problem with canonicals after moving sites from local -> staging -> live.

On previous sites, I’ve been lucky where a Yoast plugin update corrected the domain.

Is this a bug in the plugin? Shouldn’t the domain part of the canonical be derived from the site domain? Or at least have a button to say ‘reset canonicals to current domain’ perhaps? Just a thought.

Thanks for the heads-up on the test helper plugin, very useful.

Just a quick follow up – if you’re editing the default args, another useful one would be controlSize, otherwise the controls are huge on small maps.

https://developers.google.com/maps/documentation/javascript/reference/map#MapOptions.controlSize

Best regards

Closing as resolved.

Just closing this one off – I’ve used your plugin on a second site, and the zoom option is clearly there in the meta box on the right. Maybe it was hidden by screen options when I initially posted.

Thanks for replying. With further recent testing, it seems that Manual Orders -> PayPal Payments go correctly to ‘processing’. It’s orders through a different processor, WorldPay in this case, where post payment the orders go to complete.

The information on your link also seems to suggest this status setting is the role of the processor:

Most gateways will report back and set the order status to Processing (payment successful) or Failed (payment unsuccessful). If the shop never receives either signal, it keeps the status on Pending.

We’ll speak with WorldPay about this, thanks.

@bundo just passing through searching for something else, but read your post.

The transition won’t work with a height css declaration, but if the height of your menu is going to be consistent, try {max-height: 140px!important} instead, changing 140px to whatever you need height-wise – this should still allow the transition:

.onepress-menu.onepress-menu-mobile { max-height: 140px !important; }

Well the question wasn’t answered directly, but logically one would assume the password would be saved in plain text so the plugin can connect with the SMTP provider.

We changed the SMTP password with our provider, and went through all websites to update the plugin and change the password in each install, so yes I’ll mark this as resolved.

@dylanauty that’s great, glad you’ve solved it. Perhaps that’ll fix the OP’s original query too.

@nickduncan it’s the standard WP dashboard I’m referring to.

I was running updates on a client site, one-by-one, and after upgrading WP Live chat support, it changed the dashboard. Strong tags were bolder, the grey of the WP dash changed to white etc. After inspecting in the browser, it was bootstrap styling loaded by your plugin.

The site in question had the ‘notify me when I’m in the dashboard’ option enabled, if that’s any use, so the small icon was on the right of the dash. Perhaps that’s loading in the style?

The client wasn’t using the plugin, so I disabled it. That’s no reflection on the plugin btw, but the client hadn’t been as proactive with instant chat support as they thought they’d be.

Hope that helps.

I came here to see if anyone else was having styling issues.

Inspecting the dashboard, the plugin now seems to be loading bootstrap in the dashboard. Easiest way to see this is the body tag – you’ll see bootstrap styles added by your plugin.

Please can you remove this? There’s no reason to change the styling of the dashboard.

…mine have now completed, so it must have just taken longer than usual. Just thought I’d update the thread so others know to give it time.

I’m having the same problem too. I tried the ‘update database’ option, but it just gives a ‘Database upgrade routine has been scheduled to run in the background.’ message, so it looks like it relies on cron? We now have 8 pending scheduled actions that aren’t doing anything. Is there any other way to force these through?

Thanks for the comprehensive reply, and apologies if my review sounded too harsh – it was on a bad day dealing with old installs.

When you have hundreds of clients, most who are happy to have their sites updated, you’re still going to have a few non-techie clients who don’t want to pay to keep things tip-top. Sometimes they have old purchased themes that break >5.6. Moving these along is a slow process but we’re getting there.

I stand by the point that plugins shouldn’t display non-dismissable prompts. If you have 10 plugins doing that you’d have no screen real estate left. I acknowledge that WP asked to help out on this, but the way WP does this, from core, on the dashboard seems a good balance to me rather than taking up the screen space. Perhaps consider making it dismissable at least?

The v4.2.8 definitely upgraded without proactive action when I moved it to their new install. Also perhaps the on-boarding wizard might be good as an option to click rather than auto-starting? Good to know the manual UA entry is coming back too.

All of my complaints were perhaps a perfect storm of frustration, so on reflection I’ll bump up my review a notch.

Best regards

Hi Andrew, thanks for looking into it.

I’ve just spent all morning, trying it out on a fresh install, and a clone of my client site where I had the problem.

Everything was inconsistent to start with – creating new posts allowed me to embed the video normally, but trying to add videos to existing posts (that existed pre WP5) was hit and miss. I tried taking all of the content from the old post, including the featured image and tax settings and applying them to my new post, but that still allowed the embed to generate on the new post.

Cloning the old post, and trying to embed in that had no luck either, so I started to think it was something in post meta or transients of old posts.

On my cloned site, I installed https://www.ads-software.com/plugins/rvg-optimize-database/, and in the settings deleted transients and selected ‘Clear oEmbed cache’. Ran the optimisation. This time my old posts on my site clone (separate server) allowed the embed to generate. “That’s great” I thought, I’ve cracked it. Unfortunately when I tried this on my original site on my local machine, installed the same plugin and optimised, my local old post still doesn’t let me generate the embed.

When the embed doesn’t generate by the way, I’m seeing no errors in Chrome console or debug logging.

I literally give up. I’ll update the clients site and recreate the new posts with vimeo in them if I have to. I just wanted to report back in case you hear of anything similar.

If you’d like a copy of my local install for testing (there’s no personal data or anything confidential in it), feel free to email me – check my profile for our domain, and it’s chris@ – I can dropbox you a copy.

Thanks again

Hi @itanders, as per that link above, that snippet is all you need, simply add it to your functions.php file in your theme:

add_filter( 'rp4wp_append_content', '__return_false' );

The plugin is well written – it will apply that filter every time it runs. By adding it to your functions file, you’re just letting your WordPress installation know you have a filter to add whenever the filter is applied.