drking

I’m sorry to say I ended up rebuilding the entire site – would have moved away from WP if I could because it was a long process. I’m running what was the latest version. But who knows when the wretched thing is next going to say, “Hiya – you’ve been updated (and by the way your site doesn’t work any more)”. The “Hiya” was particularly galling :).

James’ advice above is very good – hope it helps you. But I suspect that the update itself was buggy, and that’s why there were probs.

OK, thank you – that’s very helpful.

I renamed the plugins folder to ‘pluginsoff’ via ftp. All plugins deactivated, and I got in as admin. I renamed the plugins folder back to ‘plugins’, and activated the plugins one by one, logging in on a different browser each time. There are two plugins with issues – Theme My Login, which causes the redirect loop I think. And WordPress Access Control, which prevents admin from seeing the actual website while logged in.

The update to Theme My Login needs WP 4.5 or so. There’s no update to WordPress Access Control.

I could update to the latest WP 4.6.1, but it’s very unlikely that the issue with WordPress Access Control will go away.

So I either have to replace WordPress Access Control, which probably means writing a new plugin myself, or trying to change the existing code. Or I have to go back to my previous version of WP.

Can I rewind the version somehow?

Thanks again – I’m a lot further forward than I was

Chrome (on a mobile) says: “This page has a redirect loop. ERR_TOO_MANY_REDIRECTS”

So it’s presumably not a browser issue. Any idea the the best way to tackle this?

Many thanks.

Brilliant – thank you.

Perhaps I’m a little too cautious about accessing the WP database in a separate program – one worry being to acquire the password (yes, I know it’s in config.php or somewhere but that’s presumably not readable by another progam so it needs human intervention – less than great here as I’m not the human who’d have to do that). But it’s not out of the question, I agree. I’d not need CRON in fact, as any new request for a pdf could check for old files and delete them. So yes, this is one possible solution.

Another idea I’ve come up with is to have a <a href='xyz/file.pdf' onclick='myfunction()'>construct where I write the pdf file url, but only construct the file itself on the click. That would probably work too, if the function returned true. My previous idea to make a javascript function return a pdf file url to href (<a href="javascript:myfunction()">) doesn’t work; there is probably no specification of what should happen (I’ve waded through the HTML5 spec), and 2 browsers I tried simply return the text output of the javascript function to a new page, even converting boolean values to text.

But the one I really like is to call wp-admin/admin-post.php. I’ll try that first.

Thanks very much – very helpful.

Thanks. Sending the right headers etc is actually easy outside WordPress – FPDF handles that, and it works well. The issue is to stop WordPress sending anything else (eg the normal webpage headers).

Overnight I’ve wondered whether my link could be something like
<a href="javascript:myJsFunction();">
where the javascript function calls the WP ajax mechanism which generates a pdf file in a unique folder (and deletes old folders), then returns the url of the generated file.

I need unique folders because I want the pdf files to have a sensible name, rather than a unique name.

Anyone any experience of this? Will the browser respond to the href that the js function returns in all circumstances/with all browsers?

Thanks

Thanks again.

Yes, it does have to redirect to the new site. http://www.oldsite.org.uk/dir/?page_id=19 has to redirect to http://www.newsite.org.uk/?page_id=34

The repidtables site suggests:
Redirect 301 /dir/?page_id=19 http://www.newsite.org.uk/?page_id=34
presumably to be included in an .htaccess file in the root directory, whereas I’ve been using an htaccess file in /dir/

But it still doesn’t work. I suspect this may be to do with the exact url that’s required – I don’t understand the mechanism, but the existing .htaccess file in /dir/ has a line:

DirectoryIndex index.cgi index.php

which may possibly already be doing some redirection?

This is a one-off task – I actually don’t need to understand – I just need a line that works and to know where to put it 🙂

Thanks

Thanks for the reply – but this is an even more basic question than you have answered I’m afraid. For example I have a file myplugin.php which contains (at the top, not in a function):
// enqueue and localise scripts
wp_enqueue_script( ‘my-ajax-handle’, plugin_dir_url( __FILE__ ) . ‘ajax.js’, array( ‘jquery’ ) );

(and a whole lot of other stuff of course). It works – I can do clever things with Jquery. But at some point WordPress must open up the file myplugin.php, find the line wp_enqueue_script(…) and execute that. When does it do that?

Almost certainly I have misunderstood some basic concept that everyone else knows…

Thank you!

I’d estimate 70 – 80% at least. Possibly more.

That’s my worry :(. If I was addressing a room of 1000 people and only 70% could hear me, then 300 could not. That would not be acceptable.

I was really hoping that designers would have realised by now that the same applies to websites… that someone would have done a survey and made a list of the top 95% of real browsers out there (how many? – less than 20 I bet) and tested a theme on them. I was hoping that it wouldn’t be necessary for each individual web designer to do that work for themselves (or not I suspect!)

Is there not even one theme that claims to be OK with 95% of actual browsers?

Thanks yet again 🙂