Mick P.
Forum Replies Created
-
Forum: Hacks
In reply to: WP Automatically escaping GET and POST etc globalsHats off to WP. I think it’s probably the classiest CMS platform for websites going. It’s built around publishing pages which is something about the internet which is probably not going anywhere, and probably for good reason, and is not crowded with nonsense.
It would be interesting if it became a de facto standard for publishing websites at some point. Which would I think mean standardizing/sanitizing around a lot of the pitfalls that are out there.
As for the wp-admin pages (which I am more concerned about) WP has now a concept of “screens” and therefore the plugin that generates the screen should be the owner of the screen. Other plugins can augment that screen, but they should be expected to evolve alongside the plugin. The reader side is pretty simple I am assuming. I try to lure readers into the content generation side of the site by offering more interactive goodies inside.
As for prefixing get/post data, that’s not so bad for POST. But for GET that just makes the URLs crazier. And often POST/GET overlap. Therefore I don’t think that’s practical. Therefore there should be a mechanism for at least recognizing collisions where they exist so that developers can work around them. If WP can enforce that somehow, then it would be doing some good in terms of stabilizing the environment instead of doing bad, like by clobbering GET/POST data with slashes 🙂
Point 3. The MQ detection/circumvention opportunities for plugins should be decoupled from whatever solution is ultimately prescribed for WP as a hole. The ultimate goal I am assuming is to remove the slashing entirely. It’s not like it’s hard to slip in a single off/on status check that says that the slasher has finally been defeated.
Until that’s in there any change that does away with MQs will mean all Plugins prior to the introduction of such a check can be assumed to be broken or suspect (depending on if they need inputs that would be slashed)
Forum: Hacks
In reply to: WP Automatically escaping GET and POST etc globalsThanks for all the info. Hopefully others will be able to find this one way or another.
Some food for thought,
I think there are probably more users who develop private “plugins” then there are viable shared plugins.
If your plugin is doing something page centric then you can reasonably assume ownership of the _GET/_POST content on a per value basis if its your page’s turn to bat. There should be a list of the get/post values that are used generally (on every page) by WP so not to collide with those.
To my mind considering the hole WP has dug for itself. I would start by having a simple way for plugins to figure out if WP has finally dropped its MQ regime for good. Even if you don’t have a plan to get out, the sooner that is added the better, so plugins and new development can rely upon it ASAP.
Then I would add either an action hook into the mix during which the MQs are being installed so a plugin can prevent the slashing of any value they are interested in. Then you can raise a red flag there too if a plugin is claiming ownership of a core WP value — or even if two plugins (hooks) are claiming ownership of the same value. Indeed that might be a very good idea in general (tracking ownership of the values)
A blacklist global that even administrators can easily setup in wp-config would be good to. For administrators you often need to arrange situations that cannot be dependent on whether a plugin gets to load or not, because sometimes plugins fail, and that would leave your defenses down.
Ultimately I’d say the very simplest solution is best because this is such a low level matter. Obviously if there has not been any traction after all this time, it seems like its time to do something/anything before things go any further.
If there isn’t, there should be a Magic Quotes page in the codex, and there should be a mention of the matter in the Plugin development pages. It’s something people can easily not be aware of, because it only comes into play when you need characters in your GET/POST data that would get slashed, and then maybe slashed again, and again. So it has a creep quality that should warrant special attention.
Forum: Hacks
In reply to: WP Automatically escaping GET and POST etc globalsThanks for the heads up.
This seems like something that has only recently received attention.
I guess what developers need to know is…
A) When (and to a less extent where in what code file) is the WP slashing done… like action hook wise.
B) Precisely, as in exactly, what the slashing entails. The slash algorithm, and what gets slashed.
C) How to detect if it is being done or not.
Without any of this information its pretty mystical territory.
Forum: Hacks
In reply to: Why/how does WP obfuscate the js include files? Needing to debug/reverse them.That’s what I was looking for. It would be nice if the streamlining was a turn on feature. A good compromise would be to put a comment in the top of the compressed files I think. Still that would not be helpful to non-administrators trying to replicate what their favorite site is up to.
I noticed in load-scripts you can pass ?c=1 to disable compression for some reason. If there was an analog for undoing the script mangling that would be very handy.
Minify is a tech word I’ve never stumbled across before. Regardless, minified code is a subset of obfuscated code.
PS: I don’t think this is a good practice for WP. Bare minimum define(‘SCRIPT_DEBUG’,true); needs to appear in wp-config.php so administrators can be aware of it from day one. It should be uncommented with a comment that says, comment this out to minify js files or whatever. Or an option could alternatively be in the settings pages.
EDITED: @claytonjames
I appreciate the effort if you uploaded that code yourself. I think we ultimately found a better solution. But just to be clear, the -all file includes more than the swfupload.js file alone. I’m sorry, I can’t tell off the top of my head if everything is in there. It’s not clearly labeled -all though.
Forum: Hacks
In reply to: Why/how does WP obfuscate the js include files? Needing to debug/reverse them.^Yes, obfuscated. You can see easily how the two files differ.
The second (http://core.trac.wordpress.org/browser/branches/3.2/wp-includes/js/swfupload/swfupload-all.js) is used by WP. So if you want to debug in a browser you are stuck with that. It is a conglomeration of more than just swfupload, therefore you cannot simple replace the files.
This obfuscation I think is a bad practice. But I would just like a solution. Like how the files are obfuscated, so that they can be disobfuscated at the very least.
PS: Seeing as browsers download a javascript file and then cache it, WP is not saving anyone much bandwidth at all by obfuscating the source code. It is just making the files opaque / impossible / troublesome to debug or adapt.
If a blog serving bajillions of readers needs to make the files smaller for every ounce of savings per each of its readers, that should be a plugin.
Forum: Hacks
In reply to: Why/how does WP obfuscate the js include files? Needing to debug/reverse them.A sample of swfupload-all.js:
// swfupload var SWFUpload;if(SWFUpload==undefined){SWFUpload=function(a){this.initSWFUpload(a)}}SWFUpload.prototype.initSWFUpload=function(b){try{this.customSettings={};this.settings=b;this.eventQueue=[];this.movieName="SWFUpload_"+SWFUpload.movieCount++;this.movieElement=null;SWFUpload.instances[this.movieName]=this;this.initSettings();this.loadFlash()}catch(a){delete SWFUpload.instances[this.movieName];throw a}};SWFUpload.instances={};SWFUpload.movieCount=0;SWFUpload.version="2.2.0 2009-03-25";SWFUpload.QUEUE_ERROR={QUEUE_LIMIT_EXCEEDED:-100,This is all of the swfupload files packed into one, which is loaded by load-script/s.php. The rest of the file goes on like that… no line breaks.
Forum: Hacks
In reply to: Why/how does WP obfuscate the js include files? Needing to debug/reverse them.^It is part of the media library that allows you to attach images etc. to posts. It is built into the core, media-upload.php etc.
All of the js files installed by WP are obfuscated. They are compressed to the point they are totally unintelligible… you may draw a distinction, but I don’t.