andrewpaulbowden

So I have been doing some digging and I think this may be down – on my install at least – to XMLRPC being disabled. Social seems to rely on XML-RPC to do the posting and on my setup I had it disabled via iThemes Security.

I don’t have any scheduled posts going up until Wednesday so haven’t tested this is the solution but I’ve changed the settings and will see.

If you have iThemes Security installed, try changing the XML-RPC setting to “Only Disable Trackbacks/Pingbacks” and see if it helps.

Yes, exactly the same problem ??

Vote duly noted ??

I have a few ideas how it could work – just need some time to do the work.

Hi popote – if the country in question is the UK, then yes, you can do this. For other countries however, it isn’t yet possible.

It’s something I’ll put on the list for a future version.

Hi again. I’ve found the problem. Seems I made a typo in a piece of code and some versions of WordPress accept the typo (and so display the settings menu), and some don’t (and don’t.)

I’ve just submitted a fix to the plugin directory. Once the plugin is updated, you should see the settings menu.

Hi – are you looking in the left navigation bar for the EU VAT Redirect settings page, or in the main content area? It should be on the left menu.

If it’s not there, do you know what version of WordPress you’re using?

To follow up on this, I had a thought.

I disabled Domain Mapping and suddenly QuickCache began working for all blogs.

This led me to find the route cause of the problem – for me anyway.

I have Multisite and have Domain mapping. WordPress is installed on domain1.co.uk. For site two (on domain2.co.uk), my WordPress URL was domain1.co.uk/domain2/wp-admin/, and the site URL domain1.co.uk/domain2 with Domain Mapping mapping it to domain2.co.uk.

When I changed the site URL for site two to be domain2.co.uk/ in WordPress (so the admin interface became domain2.co.uk/wp-admin/, QuickCache started working – when posts were updated, the cache was cleared.

Hope that makes some sense and hopefully helps someone else as well.

andrewbevitt – I just used that code to save me some grief. For some reason the Akismet JS was being put on the wrong domain – a stray t was being added to the end. Changed to your version and lo, it’s all fine again. Phew.

Maybe if WordPress and its plugins were efficient in their code, then we wouldn’t have to ignore them. The fact is that out of the box, WordPress plugins, themes and templates are severely bloated. I want a fast, speedy, efficient website thanks.

I would not be complaining incidentally if Akismet did what every other plugin does – fail. It’s the fact it’s doing the opposite that is the problem. If people want to have complete control, they should be able to do so. Plugins should not presume they know best.

Why? Because I wrote my own theme from scratch and didn’t bother putting in WordPress’s standard code in the header and footer. Yes, this breaks some plugins but that’s fine because a) I generally prefer to bake stuff in directly rather than use plugins, and b) I can manually add in what I need. It keeps everything under control that way – especially plugins. I was amazed by how much unnecessary crap some plugins shove in your page.

As such, I don’t bother with the version of Jquery included in WP core, and pull in the version hosted on Google’s servers instead. Which means I’m not re-loading it in my theme. Well except that I am because Askimet clearly knows what’s in my theme better than me.

As for whether those scripts are needed? Well no, they are not. I just disabled Javascript and performed some tests, and could see no problems at all. Commenting just worked. I would guess it does something at some level, but it’s not essential.

I only just spotted this myself but it’s rather annoying given I already load JQuery in my theme – to have it twice is just unnecessary bloat.

I’ve tried a couple, but recently settled on the Redirection plugin. It allows you to set up any URL to redirect, and you can import and export data as well.

Well worth checking out.

For me, the post.

I did some experiments on this on some stock sites, using default twentythirteen and twentyfourteen themes, and it works.

If I use my custom theme, it works.

So then I started slowly but surely adding plugins on the stock site. And it all worked until I got to the “Insert PHP” plugin. Suddenly Video Thumbnails completely stops working – it just won’t find the thumbnail images. Disable the plugin, and Video Thumbnails is fine again.

So clearly that plugin’s getting in the way for goodness knows what reason. All it does is allow you to put in a shortcode [insert_php] to wrap around some PHP. Strangely the two worked happily in 3.7, but I guess I’m going to have to try some other PHP plugins instead.

Unfortunately the new images simply don’t map at all – they resolutely remain on the network server.

I have just come across the “WP Original Media Path” which I’ve installed and does solve the problem for me, but it does seem that there should be another way to make this work.