[wp-hackers] wp-hackers Digest, Vol 80, Issue 6

VIJAY VERMA vijayverma2011 at hotmail.com
Sat Sep 3 05:17:53 UTC 2011


Hi
I recommend rakesh at dynaweb4u.com as an expert in PHP and MYSQL.
-------------------

> From: wp-hackers-request at lists.automattic.com
> Subject: wp-hackers Digest, Vol 80, Issue 6
> To: wp-hackers at lists.automattic.com
> Date: Fri, 2 Sep 2011 17:41:16 +0000
> 
> Send wp-hackers mailing list submissions to
> 	wp-hackers at lists.automattic.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.automattic.com/mailman/listinfo/wp-hackers
> or, via email, send a message with subject or body 'help' to
> 	wp-hackers-request at lists.automattic.com
> 
> You can reach the person managing the list at
> 	wp-hackers-owner at lists.automattic.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wp-hackers digest..."
> 
> 
> Today's Topics:
> 
>    1. MySQL expert / professional troubleshooting for	Wordpress
>       site (Ian Douglas)
>    2. Re: Filter for ' (Scott Kingsley Clark)
>    3. Re: Filter for ' (Dion Hulse (dd32))
>    4. Re: Filter for ' (Frank Bueltge)
>    5. TinyMCE plugin issues in domain mapped multisite	config
>       related to WP_PLUGIN_URL usage (Ken Brucker)
>    6. Re: TinyMCE plugin issues in domain mapped multisite	config
>       related to WP_PLUGIN_URL usage (Jess Planck)
>    7. Re: TinyMCE plugin issues in domain mapped multisite	config
>       related to WP_PLUGIN_URL usage (Ken Brucker)
>    8. Re: TinyMCE plugin issues in domain mapped multisite	config
>       related to WP_PLUGIN_URL usage (Jess Planck)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 2 Sep 2011 15:06:51 +0200
> From: Ian Douglas <ian at powerfoundation.org>
> Subject: [wp-hackers] MySQL expert / professional troubleshooting for
> 	Wordpress site
> To: wp-hackers at lists.automattic.com
> Message-ID: <3B728E32-CFD5-40E1-A945-1717A46DD875 at powerfoundation.org>
> Content-Type: text/plain; charset=us-ascii
> 
> We can't keep one site stable and need professional help.
> 
> 1. Can anyone recommend a MySQL expert, to rebuild a MySQL database driving a Wordpress site? I'm asking here first so that the person is sensitive to -- and knowledgeable about -- Wordpress.
> 
> 2. Can anyone recommend a Wordpress expert to look through our installation for possible conflicts that might explain our current instability?
> 
> This would be paid work for the right person(s).
> 
> Any pointers or recommendations highly appreciated.
> 
> Thanks,
> ian
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 2 Sep 2011 06:40:11 -0700 (PDT)
> From: Scott Kingsley Clark <scott at skcdev.com>
> Subject: Re: [wp-hackers] Filter for '
> To: wp-hackers at lists.automattic.com
> Message-ID:
> 	<205a4590-99a5-4355-bca2-1e1d379f96f8 at l2g2000vbn.googlegroups.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> > I have deactivate the default-filters.php and check many other
> > filters, but i dont find the filter for this topic. I will deactive
> > the filter on the plugin-page for use my strings; is an sql query for
> > send sql queries inside backen, only for devs. I have also list all
> > active filters and actions, but i dont find the function, to do this.
> 
> I know this one was very confusing, had to poke around deep and I
> found it a while back. Thing is, I assumed WP wasn't doing anything up
> until I found this, I thought I was going crazy ;)
> 
> What you're looking for is line 529 of /wp-includes/load.php in a
> function called 'wp_magic_quotes', which uses
> 'add_magic_quotes' (found in /wp-includes/functions.php at line 1521)
> to loop through an array (deep) and addslashes($v) to the values
> within.
> 
> It escapes $_GET, $_POST, $_COOKIE, $_SERVER, and then merges $_GET +
> $_POST as $_REQUEST (in that order), there's no filters or actions in
> the function, but it runs between the two actions called
> 'plugins_loaded' and 'sanitize_comment_cookies' in /wp-settings.php at
> line 212.
> 
> If you *absolutely had to* remove it, you could hook into
> 'sanitize_comment_cookies' to stripslashes_deep($_var) on the global
> arrays you're after.
> 
> Hope this info helps you!
> 
> -Scott
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 2 Sep 2011 23:48:59 +1000
> From: "Dion Hulse (dd32)" <wordpress at dd32.id.au>
> Subject: Re: [wp-hackers] Filter for '
> To: wp-hackers at lists.automattic.com
> Message-ID:
> 	<CAL4EHfkk989f_CXK=+FTN33euTQZb=g3hs9zbBATGChnDCHbMQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 2 September 2011 23:40, Scott Kingsley Clark <scott at skcdev.com> wrote:
> 
> >
> > If you *absolutely had to* remove it, you could hook into
> > 'sanitize_comment_cookies' to stripslashes_deep($_var) on the global
> > arrays you're after.
> >
> 
> but *NEVER do this* and store the result back into the superglobal. Not
> unless you want to open your site up to security issues from all the plugins
> out there that expect slashed data - and break Quotes in posts/comments too
> at the same time. (Tip: This is why WordPress can't just turn off Magic
> quotes and be done with it. Doing so will introduce security issues into
> older plugins, and well, most new ones too)
> 
> For a ray of sunshine in an otherwise dark world of Quoting, Pretty much
> every Developer out there wants to get rid of it, it's just the security
> implications it'd cause.  See
> http://core.trac.wordpress.org/ticket/18322for very early discussions
> of moving away from it.
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 2 Sep 2011 15:56:21 +0200
> From: Frank Bueltge <frank at bueltge.de>
> Subject: Re: [wp-hackers] Filter for '
> To: wp-hackers at lists.automattic.com
> Message-ID:
> 	<CAH9UVvFh2QvTSJwEswk-i0WUyvaMdEQ_pup+LgNmBV22SkHm-Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hello at all,
> 
> and many thanks for your replies and solution tips!!!
> I will see for your great tips and find an solution; yes i have now
> only an idea to filter my post to reset the Magic Quotes, but i
> thought, WP has an filter and  it is easy to remove the function via
> remove_filter and this is enough. My app is via thickbox, why is an
> extra app, ready solution and i include this extra as idependent
> applikation in the thickbox, only in the backend of WP.
> best regards
> Frank
> 
> 
> On Fri, Sep 2, 2011 at 3:48 PM, Dion Hulse (dd32) <wordpress at dd32.id.au> wrote:
> > On 2 September 2011 23:40, Scott Kingsley Clark <scott at skcdev.com> wrote:
> >
> >>
> >> If you *absolutely had to* remove it, you could hook into
> >> 'sanitize_comment_cookies' to stripslashes_deep($_var) on the global
> >> arrays you're after.
> >>
> >
> > but *NEVER do this* and store the result back into the superglobal. Not
> > unless you want to open your site up to security issues from all the plugins
> > out there that expect slashed data - and break Quotes in posts/comments too
> > at the same time. (Tip: This is why WordPress can't just turn off Magic
> > quotes and be done with it. Doing so will introduce security issues into
> > older plugins, and well, most new ones too)
> >
> > For a ray of sunshine in an otherwise dark world of Quoting, Pretty much
> > every Developer out there wants to get rid of it, it's just the security
> > implications it'd cause. ?See
> > http://core.trac.wordpress.org/ticket/18322for very early discussions
> > of moving away from it.
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 2 Sep 2011 09:49:39 -0500
> From: Ken Brucker <ken.brucker at action-a-day.com>
> Subject: [wp-hackers] TinyMCE plugin issues in domain mapped multisite
> 	config related to WP_PLUGIN_URL usage
> To: wp-hackers at lists.automattic.com
> Message-ID: <4236B6C7-0D3F-4553-9F2D-9E49C63C1FF0 at action-a-day.com>
> Content-Type: text/plain;	charset=us-ascii
> 
> I'm working on a plugin that has a TinyMCE plugin with popup and am running into issues trying to use it in a multi-site configuration with domain mapping enabled.
> 
> What I've found is that WP_PLUGIN_URL is set to the network URL while plugins_url() returns the mapped URL.  When the admin screens use the mapped name, this is creating several issues because some elements of the screen are referenced via the network URL and some via the mapped URL.
> 
> I've got two scenarios, neither of which work:
> 
> 1) Plugin uses WP_PLUGIN_URL to register the TinyMCE plugin via mce_external_plugins filter
> 
> Result is XSS scripting violation because the tinymce popup iframe is using the network name while the admin page uses the mapped name.
> 
> 2) Plugin uses plugins_url() to register the plugin
> 
> The scripts run, but the tinymce/langs files are not retrieved because the logic in wp-admin/includes/post.php:wp_tiny_mce() around line 1498 mangles the translation.  The code tries to filter using WP_PLUGIN_URL (network name) which won't match the incoming URL that uses the mapped name.  The resulting file system path has the mapped URL path embedded so the subsequent searches for the language files fail.
> 
> What's not clear to me if the issue is the WP_PLUGIN_URL value or the code in wp_tiny_mce().  In a multi-site domain mapped environment what should WP_PLUGIN_URL be?  If the admin screen is also supposed to use the mapped URL should WP_PLUGIN_URL be the mapped domain so all is 100% consistent?
> 
> After examining some other plugins it appears the workaround is to setup a tinymce/lang	s/langs.php to do the right thing to find the .js language files.  This extra code in each plugin to do this correctly wouldn't be required if wp_tiny_mce() was able to handle multi-site domain mapped configs.  If wp_tiny_mce() did the right thing it would also lower the bar for plugins to support multi-site configs.
> 
> This has been a bugger to sort out why popups in a multi-site were failing.
> 
> -- Ken
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 2 Sep 2011 10:03:14 -0500
> From: Jess Planck <jess at funroe.net>
> Subject: Re: [wp-hackers] TinyMCE plugin issues in domain mapped
> 	multisite	config related to WP_PLUGIN_URL usage
> To: "wp-hackers at lists.automattic.com"
> 	<wp-hackers at lists.automattic.com>
> Message-ID: <50319A82-3693-48B9-8CC3-68546099C392 at funroe.net>
> Content-Type: text/plain;	charset=us-ascii
> 
> Had the same issue with other multisite installs and ended up using Andrew Ozz's method of pulling in language strings in the TinyMCE Advanced plugin. 
> 
> I'm sure there has to be a better way to handle external TinyMCE plugins, but at least this kinda works. 
> 
> Jess
> 
> On Sep 2, 2011, at 9:49 AM, Ken Brucker <ken.brucker at action-a-day.com> wrote:
> 
> > I'm working on a plugin that has a TinyMCE plugin with popup and am running into issues trying to use it in a multi-site configuration with domain mapping enabled.
> > 
> > What I've found is that WP_PLUGIN_URL is set to the network URL while plugins_url() returns the mapped URL.  When the admin screens use the mapped name, this is creating several issues because some elements of the screen are referenced via the network URL and some via the mapped URL.
> > 
> > I've got two scenarios, neither of which work:
> > 
> > 1) Plugin uses WP_PLUGIN_URL to register the TinyMCE plugin via mce_external_plugins filter
> > 
> > Result is XSS scripting violation because the tinymce popup iframe is using the network name while the admin page uses the mapped name.
> > 
> > 2) Plugin uses plugins_url() to register the plugin
> > 
> > The scripts run, but the tinymce/langs files are not retrieved because the logic in wp-admin/includes/post.php:wp_tiny_mce() around line 1498 mangles the translation.  The code tries to filter using WP_PLUGIN_URL (network name) which won't match the incoming URL that uses the mapped name.  The resulting file system path has the mapped URL path embedded so the subsequent searches for the language files fail.
> > 
> > What's not clear to me if the issue is the WP_PLUGIN_URL value or the code in wp_tiny_mce().  In a multi-site domain mapped environment what should WP_PLUGIN_URL be?  If the admin screen is also supposed to use the mapped URL should WP_PLUGIN_URL be the mapped domain so all is 100% consistent?
> > 
> > After examining some other plugins it appears the workaround is to setup a tinymce/lang    s/langs.php to do the right thing to find the .js language files.  This extra code in each plugin to do this correctly wouldn't be required if wp_tiny_mce() was able to handle multi-site domain mapped configs.  If wp_tiny_mce() did the right thing it would also lower the bar for plugins to support multi-site configs.
> > 
> > This has been a bugger to sort out why popups in a multi-site were failing.
> > 
> > -- Ken
> > 
> > 
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Fri, 2 Sep 2011 12:28:21 -0500
> From: Ken Brucker <ken.brucker at action-a-day.com>
> Subject: Re: [wp-hackers] TinyMCE plugin issues in domain mapped
> 	multisite	config related to WP_PLUGIN_URL usage
> To: wp-hackers at lists.automattic.com
> Message-ID: <88F84FFF-7A6E-4F34-AA59-70F7FD872763 at action-a-day.com>
> Content-Type: text/plain; charset=us-ascii
> 
> I ended up copying Andrew Ozz's method too (Thank you Andrew for paving the way!)
> 
> I do think there's a bug in here, just not sure if it's the definition of WP_PLUGIN_URL or in the assumptions wp_tiny_mce() makes for locating the plugin language files.  My gut instinct is that WP_PLUGIN_URL should use the mapped domain name and not the network multi-site name.  But I'm not sure what could break if such a change is made.  
> 
> I do see that both WP_CONTENT_URL and WP_PLUGIN_URL use the network name, even when the mapped name is requested for the Admin pages.  I don't have a development MU site setup or I'd play more with this right now.
> 
> -- Ken
> 
> On Sep 2, 2011, at 10:03 AM, Jess Planck wrote:
> 
> > Had the same issue with other multisite installs and ended up using Andrew Ozz's method of pulling in language strings in the TinyMCE Advanced plugin. 
> > 
> > I'm sure there has to be a better way to handle external TinyMCE plugins, but at least this kinda works. 
> > 
> > Jess
> > 
> > On Sep 2, 2011, at 9:49 AM, Ken Brucker <ken.brucker at action-a-day.com> wrote:
> > 
> >> I'm working on a plugin that has a TinyMCE plugin with popup and am running into issues trying to use it in a multi-site configuration with domain mapping enabled.
> >> 
> >> What I've found is that WP_PLUGIN_URL is set to the network URL while plugins_url() returns the mapped URL.  When the admin screens use the mapped name, this is creating several issues because some elements of the screen are referenced via the network URL and some via the mapped URL.
> >> 
> >> I've got two scenarios, neither of which work:
> >> 
> >> 1) Plugin uses WP_PLUGIN_URL to register the TinyMCE plugin via mce_external_plugins filter
> >> 
> >> Result is XSS scripting violation because the tinymce popup iframe is using the network name while the admin page uses the mapped name.
> >> 
> >> 2) Plugin uses plugins_url() to register the plugin
> >> 
> >> The scripts run, but the tinymce/langs files are not retrieved because the logic in wp-admin/includes/post.php:wp_tiny_mce() around line 1498 mangles the translation.  The code tries to filter using WP_PLUGIN_URL (network name) which won't match the incoming URL that uses the mapped name.  The resulting file system path has the mapped URL path embedded so the subsequent searches for the language files fail.
> >> 
> >> What's not clear to me if the issue is the WP_PLUGIN_URL value or the code in wp_tiny_mce().  In a multi-site domain mapped environment what should WP_PLUGIN_URL be?  If the admin screen is also supposed to use the mapped URL should WP_PLUGIN_URL be the mapped domain so all is 100% consistent?
> >> 
> >> After examining some other plugins it appears the workaround is to setup a tinymce/lang    s/langs.php to do the right thing to find the .js language files.  This extra code in each plugin to do this correctly wouldn't be required if wp_tiny_mce() was able to handle multi-site domain mapped configs.  If wp_tiny_mce() did the right thing it would also lower the bar for plugins to support multi-site configs.
> >> 
> >> This has been a bugger to sort out why popups in a multi-site were failing.
> >> 
> >> -- Ken
> >> 
> >> 
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-hackers at lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 2 Sep 2011 12:41:11 -0500
> From: Jess Planck <jess at funroe.net>
> Subject: Re: [wp-hackers] TinyMCE plugin issues in domain mapped
> 	multisite	config related to WP_PLUGIN_URL usage
> To: wp-hackers at lists.automattic.com
> Message-ID: <5BCC9977-B7CA-4D6B-99EF-2B7A8FD8226C at funroe.net>
> Content-Type: text/plain; charset=us-ascii
> 
> Most folks with mention that it has been suggested to use plugins_url() and the other helper functions. BUT I'm sure TinyMCE is partly to blame, BUT so are the strict rules to reduce XSS.
> 
> It appears that TinyMCE uses a helper function to remotely load languages using javascript. In my case this worked fine since I had a WordPress multisite in sub-directory or sub-domain mode. UNTIL I enforced SSL. Then all the TinyMCE language includes failed miserably for any external TinyMCE plugin. The only way to work around the was to include the language packs in the source code for the edit post page rather than remotely loading them via JS. It sucks, but makes perfect sense for the paranoid. I'm guessing the SSL rules for most browsers are just a tad more paranoid.
> 
> Jess
> 
> On Sep 2, 2011, at 12:28 PM, Ken Brucker wrote:
> 
> > I ended up copying Andrew Ozz's method too (Thank you Andrew for paving the way!)
> > 
> > I do think there's a bug in here, just not sure if it's the definition of WP_PLUGIN_URL or in the assumptions wp_tiny_mce() makes for locating the plugin language files.  My gut instinct is that WP_PLUGIN_URL should use the mapped domain name and not the network multi-site name.  But I'm not sure what could break if such a change is made.  
> > 
> > I do see that both WP_CONTENT_URL and WP_PLUGIN_URL use the network name, even when the mapped name is requested for the Admin pages.  I don't have a development MU site setup or I'd play more with this right now.
> > 
> > -- Ken
> > 
> > On Sep 2, 2011, at 10:03 AM, Jess Planck wrote:
> > 
> >> Had the same issue with other multisite installs and ended up using Andrew Ozz's method of pulling in language strings in the TinyMCE Advanced plugin. 
> >> 
> >> I'm sure there has to be a better way to handle external TinyMCE plugins, but at least this kinda works. 
> >> 
> >> Jess
> >> 
> >> On Sep 2, 2011, at 9:49 AM, Ken Brucker <ken.brucker at action-a-day.com> wrote:
> >> 
> >>> I'm working on a plugin that has a TinyMCE plugin with popup and am running into issues trying to use it in a multi-site configuration with domain mapping enabled.
> >>> 
> >>> What I've found is that WP_PLUGIN_URL is set to the network URL while plugins_url() returns the mapped URL.  When the admin screens use the mapped name, this is creating several issues because some elements of the screen are referenced via the network URL and some via the mapped URL.
> >>> 
> >>> I've got two scenarios, neither of which work:
> >>> 
> >>> 1) Plugin uses WP_PLUGIN_URL to register the TinyMCE plugin via mce_external_plugins filter
> >>> 
> >>> Result is XSS scripting violation because the tinymce popup iframe is using the network name while the admin page uses the mapped name.
> >>> 
> >>> 2) Plugin uses plugins_url() to register the plugin
> >>> 
> >>> The scripts run, but the tinymce/langs files are not retrieved because the logic in wp-admin/includes/post.php:wp_tiny_mce() around line 1498 mangles the translation.  The code tries to filter using WP_PLUGIN_URL (network name) which won't match the incoming URL that uses the mapped name.  The resulting file system path has the mapped URL path embedded so the subsequent searches for the language files fail.
> >>> 
> >>> What's not clear to me if the issue is the WP_PLUGIN_URL value or the code in wp_tiny_mce().  In a multi-site domain mapped environment what should WP_PLUGIN_URL be?  If the admin screen is also supposed to use the mapped URL should WP_PLUGIN_URL be the mapped domain so all is 100% consistent?
> >>> 
> >>> After examining some other plugins it appears the workaround is to setup a tinymce/lang    s/langs.php to do the right thing to find the .js language files.  This extra code in each plugin to do this correctly wouldn't be required if wp_tiny_mce() was able to handle multi-site domain mapped configs.  If wp_tiny_mce() did the right thing it would also lower the bar for plugins to support multi-site configs.
> >>> 
> >>> This has been a bugger to sort out why popups in a multi-site were failing.
> >>> 
> >>> -- Ken
> >>> 
> >>> 
> >>> _______________________________________________
> >>> wp-hackers mailing list
> >>> wp-hackers at lists.automattic.com
> >>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> >> _______________________________________________
> >> wp-hackers mailing list
> >> wp-hackers at lists.automattic.com
> >> http://lists.automattic.com/mailman/listinfo/wp-hackers
> > 
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> End of wp-hackers Digest, Vol 80, Issue 6
> *****************************************
 		 	   		  


More information about the wp-hackers mailing list