Whitegoodshelp

Many thanks.

I have the same problem. It wasn’t very helpful for the Senior Support Team at SiteGround to have answered the original poster privately instead of updating what the problem was for others.

Nice one. Cheers Nick.

Yes I was about to post a similar question. I’ve had this with another plugin too. It’s very disconcerting to get notification that a plugin has updated only to see a, “Warning: This plugin has not been tested with your current version of WordPress.”

I instantly lose confidence in a plugin when this happens. In these times where security is the watchword and we are constantly being told to install all updates immediately surely the overwhelming majority of people should be using the latest version of WordPress. So I think why would someone release an update that has not been tested on the latest version of WordPress? The only reason I can think of for the message that it hasn’t been tested on the latest version is that either it hasn’t (which is extremely hard to believe) or it has but there have been issues that have prevented the authors from claiming it is OK.

So as a user of a very excellent and useful plugin it puts me in a slight dilemma and frustration.

Yes but I’ve also learnt that I don’t need to duplicate everything in both files as I had been doing. Apparently I need the # Begin WordPress stuff, but most of the other stuff I had in there like 301 redirects and more have now been deleted and everything works OK. Many thanks for your help.

I think I just installed into wordpress folder for neatness. I knew there was a possibility of running other things (eg forums) and wanted things neatly in their own folders.

Just to update. Today I found that some of my links were broken. Old links that referred to the full location of WordPress ie in the wordpress folder. They gave a server error and didn’t even fetch a proper 404 not found page.

I copied back the # Begin WordPress code and they were restored.

It seems that this code needs to also be in the wordpress folder as it strips out the /wordpress/ from links.

For example some of my old links were like this –
https://www.mywordpresssite/wordpress/NameofArticle/

The wordpress code strips out the wordpress folder and takes people to –
https://www.mywordpresssite/nameofArticle/

Andy

Thanks. I’ve just deleted all the 301 redirects from the htaccess in the wordpress folder, the ones in the root htaccess folder do the job.

I knew it was not necessary to totally duplicate the htaccess files. Unfortunately WordPress’s instructions on how to have a wordpress installation in its own folder and stripping out the /wordpress/ from urls just says to copy the htaccess from the wordpress folder to the root which gave me the impression they should be duplicated.

Many thanks

Andy

Many thanks Barnez. I can confirm that I have the code you quote in both htaccess files. I also have dozens of url redirects,compression settings, caching settings and various other things in both files.

Since reading that I needed to copy (not move) the htaccess from the wordpress directory to the root I’ve assumed both files need to be the same – hence the duplicate.

This means every time I’ve added anything to htaccess I’ve had to do it in both files which has always struck me as strange.

I just deleted the # Begin WordPress section from my root htaccess and it produced a server error
I replaced it and deleted it from the wordpress folder htaccess file and the site appears to work OK

I’ve remembered that a WordPress help file told me to copy the htaccess file (not move it). So that means 2 htaccess files should exist. Can you clarify if the need to be exact duplicates though – or was the directive to copy (and therefore duplicate) only assuming a clean install with just the basic wordpress rewrite rules in place?

Once both htaccess files are there do any changes (such as a redirect) need to be done in both files? It seems a bit cumbersome to have to edit 2 files each time you change something?

Andy

I just had this problem suddenly appear for no apparent reason. I was getting around it by copying my article and clicking refresh on the editing page. This seemed to work for a short while as it didn’t seem to lose my work (and I had a copy in the clipboard just in case). However, the issue always returned within a short time.

I started to suspect it was OK until it auto saved my work and then the “save” and “preview” buttons stayed greyed out. I did some research and found that adding the following line to my config.php file fixed the problem –

define( ‘AUTOSAVE_INTERVAL’, 6000 ); // Seconds

It basically reconfigures the auto save time to 6000 seconds. You can put more or less in. As I always manually save my work at very regular intervals I don’t need auto save.

Can I respectfully ask why I haven’t received an official reply? I’m paying good money every month and have done for years for this service. All I want to know is when you implement an update why do I get warned that you haven’t tested it on the latest WordPress despite the latest WordPress having been out for some time?

The only reason I can come up with for the warning is that the update has been tested on the latest version but isn’t 100% compatible and you’d rather not say? It’s impossible to believe that no one has bothered to test it.

Having previously applied an Addthis update which took my site offline I don’t think my question is remotely unreasonable.

Many thanks

Exactly, I had in issue with AddThis update too last year. A new update came, I updated and it took my site offline. That’s why this is extra annoying. What they are saying is they haven’t even tested it on the latest WordPress (which frankly I find very hard to believe).

Thanks Nabil. I can confirm that after a downloading the new version everything is back to normal thank you.

Thank you for your reply. It might have to go down as one of those bizarre unexplained incidents.As it happens I’ve disabled comments section of jet pack anyway because I wanted to remove the website field from comments, which jet pack won’t allow. The plug-in that I used to remove the field only works with the standard comments form.