dgdax

Better solution is that provided by @urkekg, which makes the Duplicate Post action names more unique, thus removing the conflict with Time.ly (who seem to be stubbornly refusing to help out by cleaning up the code on their side)

See : https://www.ads-software.com/support/topic/clone-and-new-post-not-working?replies=24#post-6518664 for more details

(PS to developers : any chance of putting this correction into an official release?)

Reading other forums, this has become a fairly widespread issue, indeed caused by the WP 4.0.1 update, which is stricter than before on nested shortcodes.

Unfortunately, the latest release of The Retailer came out just before WP, and did NOT include a correction, but I have successfully managed to make it work pending the official update:

1. Locate the functions.php file in the active theme’s directory (default: /wp-content/themes/theretailer )

2. search for:
add_shortcode('accordion', 'accordion');
… there should be a single occurrence towards the end of the file

3. add the following line (near-duplicate):
add_shortcode('accordion-item', 'accordion');

4. save and test. Should be back to normal…

Hi Mandy,
We’re having the same issue – as Phil suggests this is not his plugin at fault… but don’t (yet) know what is.
I am assuming linked to recent update to WP 4.0.1, which unfortunately was auto-installed…

Please update if you have a breakthrough.
David

This seems to be a ‘standard’ issue in many WP installations – I also stumbled across it while trying to debug another issue: with debug output activated the error occurs many times. (running WPv3.9.1)

Two locations highlighted for me (in wp_includes/formatting.php):
line #448: function _wp_specialchars
line #583: function wp_check_invalid_utf8
… but could easily arise in several other instances.

To correct this, code needs to check for arrays being passed, and either reject them, or process them. I chose the latter, adding the following code to each immediately after the function declaration:
for _wp_specialchars:

if( is_array($string) ){
		foreach($string as $k=>$sVal){
			$string[$k] = _wp_specialchars( $sVal, $quote_style, $charset, $double_encode );
		}
		return $string;
	}

for wp_check_invalid_utf8:

if( is_array($string) ){
		foreach($string as $k=>$sVal){
			$string[$k] = wp_check_invalid_utf8( $sVal, $strip );
		}
		return $string;
	}

Don’t know if this is really fixing anything – but site appears to be working, and without these notices occurring.

Thanks @esmi – clearly it was a temporary issue – but what could be making WordPress show the bar on normal site pages, but not in the admin area?

My first thought was CSS – but then I found that the header was not even in the rendered html page.

It may also have been a (local) Javascript issue, as I think it’s a script that adds the header to the page (?).

… so it may also be plug-in related: I use iThemes Security (previously BetterWP Security) – which includes a “safe jQuery” option that may have temporarily got in the was.

So – still nothing conclusive, but some ideas ready should the issue arise again.

… and the problem has mysteriously resolved itself, just a few minutes after posting the above – without changing anything on the site.

However, I would still like some pointers as to what may have caused this – as there’s no guarantee that it’s really cured!

Thanks Chris – I was trying to raise it as a bug, but didn’t find the link… Also feel better about doing it on your advice!

For info : I didn’t even do as much as that – I literally opened the database.sql file in Notepad++ and selected “Encode in UTF-8” from the Encoding menu, without changing the contents at all.

This may in fact be more important than changing the DEFAULT CHARACTERSET, as it determines how the file is read by the system.

Was suffering a similar problem – accented characters and other marks being scrambled – so obviously a character set issue (migrating a site from WAMPP to hosted Unix)

Found the simplest solution inspired by another post: it’s the database.sql file that’s at fault:

– open the ZIP file produced by Duplicator
– open database.sql using editor (eg Notepad++)
– change encoding to UTF8 (was created as ASCII)
– update the ZIP, and then proceed as normal.

Spent a long time before coming across this solution – couldn’t Duplicator save the file with the correct encoding marks in the first place?

Otherwise, as many others have pointed out, it is an EXCELLENT plug-in!