Discussion:
Development version of a theme
Eric Andrew Lewis
2013-12-28 19:50:20 UTC
Permalink
Came up with something weird today, thought I would share.

A development version of a theme in a `themes/{theme-name}-dev`, which has a ton of development specific assets. Sass, uncompiled JS, documentation, Gruntfile, AI/PSD versions of images) to keep everything organized.

All these assets build into a production version of the theme (`/themes/{theme-name}-theme`) via a grunt task, which includes only assets required to run the production version of the theme.

This limits exposure of some files that may need privacy while keeping everything in one location for development.
--
Eric Andrew Lewis
Bryan Petty
2013-12-28 20:11:28 UTC
Permalink
On Sat, Dec 28, 2013 at 12:50 PM, Eric Andrew Lewis
Post by Eric Andrew Lewis
Came up with something weird today, thought I would share.
A development version of a theme in a `themes/{theme-name}-dev`, which has a ton of development specific assets. Sass, uncompiled JS, documentation, Gruntfile, AI/PSD versions of images) to keep everything organized.
All these assets build into a production version of the theme (`/themes/{theme-name}-theme`) via a grunt task, which includes only assets required to run the production version of the theme.
This limits exposure of some files that may need privacy while keeping everything in one location for development.
Under the GPL, you'd really just want to distribute the uncompiled
source code with your theme anyway though. Keeps things nice and easy
in regards to license compliance. It doesn't matter if you never use
wp_enqueue_script() / wp_enqueue_style() with the uncompiled files,
just that they are distributed with the theme.

That's of course assuming you're following 100% GPL rules of WP.org
anyway. Certainly doesn't matter if you aren't (under some
multi-license theme). What are you even referring to in regards to
"privacy"? Certainly your SASS doesn't need to be "private" from the
compiled CSS, neither does your un-minified JS.

You wouldn't maintain a separate development plugin with uncompiled
PHP source code, and then distribute a copy that's been compiled with
Zend Guard. Sure, it's encoding and code obfuscation, but it's really
the same thing that CSS/JS preprocessors and compressors do.
--
Regards,
Bryan Petty
Eric Andrew Lewis
2013-12-28 20:34:29 UTC
Permalink
Post by Bryan Petty
What are you even referring to in regards to
"privacy"?
In my case, this means original image assets (vector versions of icons etc.) that shouldn’t be shared with the world, at least for client work. It would make sense to leave them in the theme folder if everything was released under the GPL.

An alternative is probably to ignore these files on deployment rather than separate them at the theme level.

--
Eric Andrew Lewis
Post by Bryan Petty
On Sat, Dec 28, 2013 at 12:50 PM, Eric Andrew Lewis
Post by Eric Andrew Lewis
Came up with something weird today, thought I would share.
A development version of a theme in a `themes/{theme-name}-dev`, which has a ton of development specific assets. Sass, uncompiled JS, documentation, Gruntfile, AI/PSD versions of images) to keep everything organized.
All these assets build into a production version of the theme (`/themes/{theme-name}-theme`) via a grunt task, which includes only assets required to run the production version of the theme.
This limits exposure of some files that may need privacy while keeping everything in one location for development.
Under the GPL, you'd really just want to distribute the uncompiled
source code with your theme anyway though. Keeps things nice and easy
in regards to license compliance. It doesn't matter if you never use
wp_enqueue_script() / wp_enqueue_style() with the uncompiled files,
just that they are distributed with the theme.
That's of course assuming you're following 100% GPL rules of WP.org (http://WP.org)
anyway. Certainly doesn't matter if you aren't (under some
multi-license theme). What are you even referring to in regards to
"privacy"? Certainly your SASS doesn't need to be "private" from the
compiled CSS, neither does your un-minified JS.
You wouldn't maintain a separate development plugin with uncompiled
PHP source code, and then distribute a copy that's been compiled with
Zend Guard. Sure, it's encoding and code obfuscation, but it's really
the same thing that CSS/JS preprocessors and compressors do.
--
Regards,
Bryan Petty
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Continue reading on narkive:
Loading...