skila

Seems a bit ‘co-incidental’ that the latest update of Yoast breaks this plugin just as Yoast are plugging their own Woocommerce integration which has Pinterest rich pins…
The Pinterest Rich Pins plugin has worked for years without issue, now you choose to break it…

I managed to sort it by using the file from this website – possibly an old upgrade class, but it worked.

It also spreads all my child pages across the entire list of pages because the ordering has been set up for the children, which have now been re-parented to the main page.

Bad:

I want to be able to:

1. Hide / Unhide a page without messing around.
2. Keep any heirarchy that I have set.
3. If possible hide an entire tree of pages with a single “edit”.
4. When are you going to fix page ordering?

Cool – thanks for the tip on the blocking…

“The various RSS feeds read by the dashboard are indeed cached, in the database, for up to 1 hour.”

I am not sure if that is true for my system: when I put in debug in the WP_Http request function to see what is happening where I see the same URL being requested 4 times in the dashboard, surely if the results are cached in the database, then these request would not occur. Is caching turned on by default or not?

Thanks

skila

Further investigation into this problem has shown up fopen with URL wrappers to be causing the problem.

This only seems to occur with PHP 4 on my hosting package – if I switch to PHP 5 it all seems to work. With PHP 4 – the only transport I have available is fopen, which means that the system will bomb if I allow it to use this…

I can now use http.php, after commenting out the option for checking WP_Http_Fopen::test() in the file – around line 103 in the _getTransport function – I could hack the test a bit rather than this function, but you get the picture: If a transport is messing you around – comment it out, or comment them all out then uncomment 1 by 1 until you find the culprit.

Now I can still use http methods and don’t have to “return” at the top of the request function. (PHP 5)

The WP_Http_Fopen::test() only tests for allow_url_fopen – which is valid, but on my hosting, there is no way of testing if a URL is blocked by the firewall. Not sure about the slowness of Curl, but this works fine. One thing I have noticed after adding debug into the request code is that the dashboard page makes 4 requests to the same URL so if 1 call is slow, then the others maybe slow too. I know that the dashboard is a modular thing, but hey couldn’t WP cache the results of these requests or something so that the returned data could be reused…

1. I would recommend allowing users to select which transports to use in order to override the system – it’s alright checking, but because of the issues with external library versions, etc. It might be nice to allow people to tweak the settings to suit them.

2. If you are not caching the URL requests offsite, please do, or make it a lot easier to turn them off…

Thanks

skila

Hi,

I had a similar problem with the Upgrade to 2.7 or a Fresh Install on 2.7 appearing to run “slow” – pages would not load at all it seemed.

Remembered a similar problem with my hosting provider from many moons ago and realised it might be a similar thing.

My hosting provider’s (Supanames) firewall prevents PHP using fopen wrappers to http connections outside the firewall unless you specifically request domains that your site is allowed to connect to. Not sure if this is a problem with anyone else, but as soon as I hacked http.php it works fine.

My guess is something changed in the 2.7 code to use a different method of calling external URL’s – when this is done on my hosting, it just hangs and never times out or anything.

Anyway, hope this helps some people even though it’s a long way down the list.

And just to add my 2c – as WordPress is used on a huge number of servers, the server setup’s may be a problem, but WordPress maybe needs to take this into account a bit more so list mod’s stop throwing their toys out of the pram every time someone takes a poke at WordPress because they are frustrated that their apparently easy to upgrade / install piece of software does not work. Just because its OS does not mean it’s not subject to quality standards. The base quality standard being “does it work for me”?

Later.

Ski

C’mon guys, you’ve known about this for 5 months and have not come up with a fix. This is a bit pants – we know Adobe changed stuff, people have been talking about it for ages and they told you what the problem was.

I know the issue is with SWFUpload, but that’s OS too – how come none of the WordPress coders have mucked in to help fix SWFUpload, which WordPress relies on so heavily – what happened to the Community in Open Source Community?

Not impressed and still waiting.