najamelan

I now use HTTP_BLOCK_REQUEST as well.

I made changes to the wordpress core in order to make the user interface consistent with the fact that it cannot connect to the internet.

You can see my changes on github.

This definitely is a wordpress bug. Moreover it’s a security issue, cause it most definitely leaks that you have wordpress running, as well as the plugins you have and probably also your site url or blog name. You might not always want that, and for security you might run a server that doesn’t allow outbound connections.

Working around this is not easy, but I think that there are several options.
– hosts file
– firewall
– php.ini settings disabling the functions that connect out

still haven’t found anything convenient though.

proposed change:

if( isset( $meta['sizes'] ) && is_array( $meta['sizes'] ) )

That is without looking at the consequences of what happens if it does not exit, but it will at least avoid the php notice.

same issue here…

I suppose potentially one could remove the plugin and reinstall after getting a new username.

two ‘s up.

Leaving the .htaccess gives 500 internal server error for everything coming out of the view directory (css, js and images)

Deleting it would presumably leave a security issue with files being readable by the public.

Could you please clarify what this risk is and if there are workarounds for people in a shared hosting environment where often one can’t have Override All…

Hi,

thanks for the fix. Don’t worry about credits, at least not for me (and I didn’t even dig into the code to actually solve it).

On time spent, well, it’s my head as well, what could be the difference between a dev and production server… Debug mode should have been a good candidate since it only requires changing one line of code in order to test it.

Unfortunately I’m depending on ftp to deploy, so errors can easily be made so what I actually did was comparing all the files on the server and downloading everything to see if I had differences.

Also it is peculiar how at least my debugging mind works. Since RRU was only throwing notices I didn’t make the link to the media library stuff. Then because in a sensible world, where the media library already has all the information it needs to insert a media in the article, I never figured they would do an ajax call, so that didn’t ring a bell. On top of that you would expect well behaved javascript to show an error message of some sort in case an ajax call returns wrongly formatted data, but it doesn’t.

Many wrong suppositions leading to inefficient bug solving. Reminds me of zen and motorcycle maintenance and the story of Archimedes (what is the moral of the story? – you have to listen to the wife, take a break!)…

well, so in ajax it does matter not to have notices… see the other thread about WP 3.5

I have the following problem: when in the new 3.5 media library when I click the insert in post button, the media library closes, but no image appears in the editor.

The reason it all fails is because appearantly wp changed to relative url’s for images (hey that’s the good new, no?) and so RRU generates a notice.

Notice: Undefined index: scheme in …/root-relative-urls/sb_root_relative_urls.php on line 142

So this sends php errors to an ajax call, and that is often fatal since js expects json data…

And it explains my two days of headache as to why my dev and production machine where showing different behaviour.

The solution is probably quite simple, as any url that starts with a slash is already root relative, and so the plugin does not need to do anything in that case.

OK, for people having this on production servers, you should disable DEBUG mode in your wp-config.php and for the others I suppose we have to fix it ourselves or wait for an update.

I’m sorry, I didn’t realize it only did comments…

It might be worth doing posts also, because kses sucks for posts as well…