[wp-hackers] Child themes, theme revisions, and the theme editor

Mike Schinkel mikeschinkel at newclarity.net
Tue Mar 23 05:50:42 UTC 2010

On Mar 23, 2010, at 1:23 AM, Andrew Nacin wrote:
> Quoting Mike Schinkel:
>> What's more if till be nice if you can sandbox an entire theme because a
>> broken php tag in almost any page can bring down a although I know this
>> would increase the scope of work.
> Thanks for the feedback. It's not scope of work as much as it is impossible.
> That's perhaps a strong word, but testing out a template file by simply
> including it in a sandbox would result in fatal errors due to undefined
> functions. (Checking for only parse errors can only be achieved via CLI.)
> And, on the basis of the file name alone, due to the template system and
> various hooks, you cannot determine which page on the frontend will use it
> (which you would have to be able to do to ensure no errors are simply
> because the files weren't included the way the theme intended them to
> be).

Impossible?  Difficult maybe, but impossible?  What if we eliminate some assumptions?

What if WP is modified to allow a theme to be loaded temporarily via URL parameter without changing the current theme? For example, the following could load the site using a twentyten theme.


Then, have the new editor create a child theme of the current theme as a sandbox behind the scenes. This child theme would only have the file(s) the user is currently updating. When the user saves a file the new editor would use an HTTP get (via AJAX, via the server or via probably both) to load the site using the sandboxed child theme and check for the closing '</html>'.  If it gets it the editor accepts the change and copies the changed files to the current theme otherwise it keeps the files in the sandbox and notifies the user of the error. 

Why won't this work?  I could easily miss something, but it seems sounds to me.


More information about the wp-hackers mailing list