fneumeier

With that info, I can dig deeper into the issue here as well. Thanks!

Ist der Gedanke so abwegig, dass er nicht einmal eine Antwort wert ist? ?? Ich f?nde ein solches Feature tats?chlich als enorme Erleichterung …

Herzliche Grü?e
Franz

Perfect, thanks a lot!

Yes, it does; but I guess it’s not so much the fault of your plugin (which is great) but some issues with my configuration which I don’t have the time to iron out quickly by now. So just safely back to what I had before and then I’ll start a new approach later when I have the time for it …

just to let you know so you don’t have to spend time on bugfixing: I’ve switched back to my former AMP solution for various reasons, so the URLs above do not reflect the output of the AMPforWP plugin anymore …

Hi Ahmed,

okay, thanks! An example page, that’s not being tracked, is: https://www.cruisetricks.de/sechstes-royal-class-schiff-soll-discovery-princess-heissen/amp/

… while without /amp/ it’s been tracked perfectly fine: https://www.cruisetricks.de/sechstes-royal-class-schiff-soll-discovery-princess-heissen/

• This reply was modified 5 years, 5 months ago by fneumeier.

Is this plugin still maintained and supported? Just wondering as there is no answer what so ever ??

I’ve installed Shortcake UI 0.7.3 and the issue doesn’t appear there. So it obviously is a bug that came with version 0.7.4.

I tested much further and it seams that this is a general bug in Shortcake UI. The issue doesn’t only appear with ARVE, but it appears as soon as ANY plugin or (or code in the functions.php) registers a shortcode with Shortcake UI. It even happens with the Shortcake UI Example plugin … That makes Shortcake UI literally unusable. Any suggestions, please?

I have the same issue. The error message appears at the top of every webpage and at the beginning of the content of every single post.

Any suggestions, please?

Thanks and kind regards,
Franz

Okay, thanks!

Just to add a thought to this – might be helpful für some: I had the same issue until I recognized I was working on a WordPress installation in a password protected path (i.e. testing environment) – hence the internal call of wp-cron.php was blocked by the webserver. removes the password protection in the .htaccess and voila, the plugin was doing its job.

Okay, thanks. I was just wondering whether it might be possible to do the clean-up in batches, i.e. delete 500 transients, check whether there are still some left, then start a new process to clean the next 500 transients and so on until the job is done …

Anyway, I’ve solved my issue by deleting it manually, though not being a MySL expert at all (like probably most users of this plugin), it took me several hours to a) find the resaon for the issue and b) to figure out how to delete these transients manually.

issue solved after manually deleting the transients in the database

Thanks for the hint – I found the issue and it’s simply “stupid me” … I’ve used Shortcake in my functions.php and just used the code from dev.php as a starting point. Hence, I also copied this error message for the case that the plugin is being deactivated. Issue solved by reactivating the plugin as I definitely need it anyway ??

Ja, bitte, bitte! Die Funktion, Spam nach Sprache und ggfs. L?nder-IPs zu filtern, war Gold wert!