[wp-hackers] Are depreciated items ever removed from core

CloudPress Hosting cloudpresshosting at gmail.com
Thu Dec 6 06:20:33 UTC 2012


The only concern with leaving it where the end user can access it is being
accidentally deleted i don't know why anyone would want our need to effort
it delete it from their own plugin code.
On Dec 5, 2012 8:07 PM, "Andrew Nacin" <wp at andrewnacin.com> wrote:

> On Wed, Dec 5, 2012 at 10:37 PM, CloudPress Hosting <
> cloudpresshosting at gmail.com> wrote:
>
> > I was looking at using my-hacks.php I have a very specific use-case
> where I
> > need to write a mu-plugin but I cannot have it in wp-content wither the
> > other plugins. I am hosting sites for clients and they have access to
> > wp-content to manage their own plugins, themes, ect. I need to add
> > functionality where they cannot access the code. I considered writing an
> > mu-plugin which just includes another file outside of wp-content where
> the
> > actual code would reside but I don't want the clients removing it. I was
> > just going to hack core to include a file in the root WordPress directory
> > where all the plugins are loaded and saw the reference to my-hacks. At
> > least until that gets taken out all together I can avoid hacking core I
> > figured and just was wondering what the chances of it being removed are.
> >
>
> my-hacks?! Wow, was not expecting that one.
>
> We almost removed my-hacks all together a few versions ago. Every time I am
> reminded of its existence, I am reminded I have always wanted to remove
> it. Wouldn't be surprised if we actually do it one time.
>
> First off, mu-plugins doesn't need to exist inside wp-content. It can exist
> elsewhere, you can set it with WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL in
> wp-config.php.
>
> Or, since you expressed a preference for them to still control mu-plugins
> (why, I'm not sure, it's really designed for this kind of advanced usage),
> you can simply specify your own custom directory, then have that directory
> additionally include everything in wp-content/mu-plugins, just like core
> does.
>
> The only thing you'd need to do is filter plugins_url() (where
> WPMU_PLUGIN_URL is used), to ensure that any instances of plugins_url() in
> their mu-plugins point to the right place. Or, define DIR in one place
> (yours) but URL in the other place (theirs), and make sure any plugin_url()
> calls you have in your mu-plugins work. So:
>
> define('WPMU_PLUGIN_DIR', '/secret-plugins' );
> define('WPMU_PLUGIN_URL', '/wp-content/mu-plugins' );
> and copy-paste-modify the directory-traversing code
> from wp_get_mu_plugins().
>
> You still need to be careful about file permissions, of course. They can
> easily run PHP code to locate that file, read it, and depending, edit it.
> They could also run PHP code that unhooks it or otherwise mitigate what
> your code does.
>
> So, the lesson is: don't let users run untrusted code if you want a closed
> environment. Really not sure how we got here from my-hacks.php and
> deprecated functions, but here we are. (Please be a bit less obtuse
> and ambiguous when posting to the list.)
>
> Nacin
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


More information about the wp-hackers mailing list