Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
How WordPress Plugins Should Handle Front End Resources

How WordPress Plugins Should Handle Front End Resources

This is a WORK IN PROGRESS intended for fleshing out and feedback

It's very common for people to be unhappy with how a WordPress plugin adds front end resources to their site. If a plugin needs CSS, the plugin will add a <link> element to that CSS. If the plugin needs JavaScript, it will add a <script> to that JavaScript.

Plugins do this because it works. It's damn important for a WordPress plugin to work, even in adverse conditions. They rightfully want good ratings and little customer support.

But this comes at the cost of additional HTTP requests. In optimizing front end performance of a site, reducing the number of HTTP requests is a huge thing. Front end developers want to decide and control how front end resources are being handled, and WordPress plugins don't typically make this easy on them.

Here's an approach for plugin developers that can make everybody happy. The plugin still "just works" as well as it did before. But for people wanting to avoid those requests and deal with assets themselves, it allows that.

If the plugin needs CSS...

  • Default to including it in the wp_head hook.
  • Have a setting to not include it there, then provide the required CSS. Perhaps in a <textarea> for easy selecting and copy-and-pasting for the developer to put it somewhere in their own project.

If the plugin needs JavaScript...

  • Default to including in the wp_footer hook.
  • Have a setting to not include it there, then provide the required JavaScript. Perhaps in a <textarea> for easy selecting and copy-and-pasting for the developer to put it somewhere in their own project.

It might look something like this:

img

If the plugin needs images...

  • Is it possible to not use images? If so, cool, do that.
  • Can you use SVG? If so, cool, use inline <svg> where you can (e.g. you can use inline Data URI SVG in add_menu_page).
  • If you need raster images (JPG, PNG, GIF), can you data URI them right into the code?
  • Always optimize images with tools like SVGO for SVG or ImageOptim for raster images.

"Just use something to handle this for you!!"

There are plugins out there that concatinate assets for you. (examples: MinQueue and W3 Total Cache). I'm sure they do a pretty good job. But this shouldn't be the final answer. This isn't something automation is the perfect solution for in every case. What if they get the ordering wrong? What if you really need a particular as asset to load in a particular place? What happens on pages with a one-off script? Shouldn't it continue to use the presumably-well-cached script used on most other pages rather than make a new one?

A performance-focused developer can make the best decisions when it comes to what assets should be concatinated (and which shouldn't) for the best use of caching throughout the site.

Feedback

  • Is all this factually correct?
  • Is there anything that can be explained better? Is the terminology correct?
  • Can we make an example plugin that demonstrates these concepts?
@tevko

This comment has been minimized.

Copy link

tevko commented Sep 29, 2014

I know nothing about making UI's in the backend for plugins, but this is a really good idea, and should be the standard for plugin development. All feedback points look good to me.

@timstl

This comment has been minimized.

Copy link

timstl commented Sep 29, 2014

Plugin updates are the problem that stand out to me. I guess you can also include a special notification if you issue a plugin update that includes JS/CSS changes. This way the project owner knows to update their own files. But to me that seems like more of a headache for the project owner than using something like W3 Total Cache.

If ordering is an issue with W3 Total Cache, you can use manual mode and reorder scripts. It can be a pain, it's not ideal, but I'm not sure maintaining a separate copy is easier.

edit: I guess easy is not really the goal here, so those points may not be all that relevant. But I think JS/CSS updates within the plugin are still something to think about with this type of interface.

@drainpip

This comment has been minimized.

Copy link

drainpip commented Sep 29, 2014

Perhaps explain that using either wp_head or wp_foot should be inline. Technically you could still echo in a <link> can't you?

@chriscoyier

This comment has been minimized.

Copy link
Owner Author

chriscoyier commented Sep 29, 2014

Plugin updates are the problem that stand out to me. I guess you can also include a special notification if you issue a plugin update that includes JS/CSS changes.

Good point. If that option is activated, and the assets changed, the plugin author should take special care to let people know to update their own copies. A little bit of a pain, but I think people are aware of the costs when they go down this road?

@justintadlock

This comment has been minimized.

Copy link

justintadlock commented Sep 29, 2014

One easy way to overcome some of this is to simply print the CSS or JavaScript within <head> or the footer rather than loading extra files and causing additional HTTP requests. This is assuming we're not talking about a lot of code.

If we are talking about a lot of code, I don't see much of a problem with loading the extra resources. Let some concatenation plugin handle this if it's a problem for the user.

If a user is WP-savvy enough to be copying and pasting styles/scripts (scripts in particular), then I don't see an issue with simply allowing them to dequeue the file and loading things how they want. That puts the responsibility for checking for issues with updates on them.

@marcmchardy

This comment has been minimized.

Copy link

marcmchardy commented Sep 29, 2014

Are there ways to auto compile a directory of wp css/js assets? similar to grunt? WP plugins could feature the existing link methods as well as a 'smart compile' method. When plugins update they trigger a compile task to generate new combined assets? I'd definitely keep an eye out for and prefer to use plugins that supported this type of functionality.

@jonsherrard

This comment has been minimized.

Copy link

jonsherrard commented Sep 29, 2014

Can you use something like gulp.src's globbing functionality for concetanation. For example

gulp.src([
  "../../plugins/**/gallery-plugin.js",
  "../../plugins/**/social-plugin.js",
  "./theme-src/js/my-handwritten-js-file.js"
])
  .pipe(concat())
  .pipe(uglify())
  .pipe(gulp.dest('./js/compiled.js');

As long as the plugin filenames stay the same, throughout updates, that should keep everything in order.

Do plugins have a list of locations for required css and js files currently?

@chriscoyier

This comment has been minimized.

Copy link
Owner Author

chriscoyier commented Sep 30, 2014

@justintadlock:

All good points.

You have an awesome post on doing this manually: http://justintadlock.com/archives/2009/08/06/how-to-disable-scripts-and-styles

Let some concatenation plugin handle this.

I don't love that. I mention that in the post above. I want to do the concatenation because I know I can do it right.

If a user is WP-savvy enough to be copying and pasting styles/scripts (scripts in particular), then I don't see an issue with simply allowing them to dequeue the file and loading things how they want.

Allowing them to dequeue is exactly what I know that I'd really like. I don't want to dig around and figure out how to do that (e.g. figure out what you named the stuff you queued so I can write my own little plugin to dequeue it). I'd rather click a radio button and be handed what I need to do things my own way.

I wonder if WordPress itself (or yet-another-plugin) could give me a settings page where I could click-to-dequeue anything that is being enqueued by any plugin.

@peterwilsoncc

This comment has been minimized.

Copy link

peterwilsoncc commented Sep 30, 2014

I wonder if WordPress itself (or yet-another-plugin) could give me a settings page where I could click-to-dequeue anything that is being enqueued by any plugin.

A late running check of $wp_scripts and $wp_styles could provide this and set up a page similar to that in the original post.

function pwcc_check_enqueued_scripts() {
  global $wp_scripts;
  // do stuff here
}

add_action( 'wp_print_scripts', 'pwcc_check_enqueued_scripts' );

I share @justintadlock's concern about exposing the dequeue functionality in the admin, too easy for accidental dequeuing.

@chriscoyier would an admin page exposing what files are enqueued, by which plugin, and its handle be acceptable? An advanced user would still need to dequeue in code.

Back to the point, something needs to be exposed to assist users/theme authors reduce the number of HTTP requests. The number of files added by WordPress can balloon too easily.

@patrick-wc

This comment has been minimized.

Copy link

patrick-wc commented Sep 30, 2014

I think we should include more image optimisation tool links. There are web based tools like Smush.it™, Grunt addons like grunt-contrib-imagemin Mac tools like ImageOptim and Windows tools like FileOptimizer available. Not everyone uses macs.

I hadn't thought of plugin updates, that is a good point. But I agree with Chris, if you are already doing this you should check the js/css when you update anyway, with a text comparison tool for example.

@justintadlock
If a user is WP-savvy enough to be copying and pasting styles/scripts (scripts in particular), then I don't see an issue with simply allowing them to dequeue the file and loading things how they want. That puts the responsibility for checking for issues with updates on them.

Some front end developers are savvy enough to concatenate and minify them but are not comfortable enough to read or understand the PHP inside a plugin in order to find a relevant hook, if it even exists.

@NateWr

This comment has been minimized.

Copy link

NateWr commented Sep 30, 2014

I have to agree with @peterwilsoncc and @justintadlock. Rolling the kind of web-based admin interface you suggest into every plugin's settings page is a bad idea. It will result in a lot of inconsistency, scattered resources and UI bloat in the admin interface (already a plugin issue). And it will expose higher-level (ie - dangerous) techniques to a broad audience of novice webmasters.

If front-end developers who are focused on performance want to take control, and don't want to rely on a big caching script, then there are better ways to accomplish this than asking plugin developers to provide a solution targeting less than 1% of their users. Here are a few approaches:

  1. Hook into the wp_head and wp_footer actions and inspect the $wp_scripts global. From there you can see every asset to be loaded (including file paths) and dequeue them before loading, then copy the files into your minified/static asset yourself. You'll have to manage plugin updates yourself.
  2. Actually do reconsider using a caching plugin. Are you aware of the $deps variable (dependencies) passed to wp_register_style, wp_register_script, wp_enqueue_style, wp_enqueue_script? Any caching plugin worth its salt ought to take dependencies into account and order them properly. If you want to inspect and handle dependency manually, check out that $wp_scripts global again where you can edit each asset's dependencies.
  3. Try a more manual minify/concatenate plugin, like this one. (Note: just found it in a quick search.)
  4. If you're worried about frontend authors having limited PHP skills, I believe it would be fairly trivial for one of us plugin authors to write something that listed all the assets enqueued on a page, and allowed you to selectively dequeue the ones you want. I'd even volunteer to write that for you if you wanted it, as a donation-in-kind for all the time I've saved and knowledge I've acquired from css-tricks.com.

On a different note, you recommend enqueuing assets using the wp_head hook. WordPress actually has a hook for registering/enqueuing earlier. That way when you hit wp_head, your assets are already registered and people won't have to play games with the hook priority. It's wp_enqueue_scripts and should be used for scripts and styles, whether in the head or footer.

@torrottum

This comment has been minimized.

Copy link

torrottum commented Sep 30, 2014

Minit is also a great concat plugin, by the way. Made by people who really care about performance

@chriscoyier

This comment has been minimized.

Copy link
Owner Author

chriscoyier commented Sep 30, 2014

@peterwilsoncc:

would an admin page exposing what files are enqueued, by which plugin, and its handle be acceptable? An advanced user would still need to dequeue in code.

Yeah! I think that's where this conversation is headed. Too problematic to ask plugin developers to do this, but I still think it needs to be easier than telling devs to dig through plugin code to figure out what to dequeue. If something could just show me everything that is queued (on any particular page) that'd be cool. And to level that up possibly give me links or print out the actual code that would get included for my copy and pasting pleasure.

@NateWr:

Hook into the wp_head and wp_footer actions and inspect the $wp_scripts global. From there you can see every asset to be loaded (including file paths) and dequeue them before loading, then copy the files into your minified/static asset yourself.

Yep, looks like we're all starting to get on the same page here. Making that into a plugin would help tremendously.

Another level up idea. Click on the things that it finds that are queued and suggest the proper code for dequeuing.

@NateWr

This comment has been minimized.

Copy link

NateWr commented Sep 30, 2014

What I'd do is throw it into the admin bar. That way you just browse to a page to see what's enqueued on that page -- a bit like Query Monitor. Actually, it doesn't sound that out of scope for Query Monitor. I wonder, can I tag people that are not already part of this convo? Let's see if @johnbillion will pull him in.

@NateWr

This comment has been minimized.

Copy link

NateWr commented Sep 30, 2014

I spoke too soon. Looks like there's already an issue for Query Monitor. He mentions an addon for Debug Bar that has this feature.

@webbeloz

This comment has been minimized.

Copy link

webbeloz commented Sep 30, 2014

Interesting topic,
but as I think about it... often inserting CSS and Javascript is used to maintain the Presets visible and then track who made it in the HTML output.
The way I see it, all plugins should be designed for a perfect and clean HTML output.
Your idea is really interesting. (Excuse my English writing.)

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 1, 2014

@chriscoyier here's a (very) rough start on the plugin for you: queue-master-v0.0.1.zip. When the plugin is activated, look for the "Assets" link in the admin bar (on the right near your profile). From there you can view assets enqueued in the head or the footer, dequeue them and click a link to view the asset.

It's only very lightly tested in my local dev environment. And the code is rather embarrassing -- I just threw it together in a couple afternoons. But have a look and if you think it's something you or other people could really use, I'll work out the rough edges, make it more fault-resilient and release it on GitHub and the WP.org repo.

@patrick-wc

This comment has been minimized.

Copy link

patrick-wc commented Oct 2, 2014

@NateWr thanks very much. I'll definitely test this out and give you some feedback over the next week or so.

@chriscoyier

This comment has been minimized.

Copy link
Owner Author

chriscoyier commented Oct 3, 2014

@NateWr: Very cool! I bet it wouldn't be too much work to flesh this out into a plugin that did the actual dequeueing itself.

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 4, 2014

@chriscoyier: This does do the actual dequeueing.

@chriscoyier

This comment has been minimized.

@chriscoyier

This comment has been minimized.

@JasonHoffmann

This comment has been minimized.

Copy link

JasonHoffmann commented Oct 7, 2014

@NateWr - Plugin looks pretty good, and is working fairly well. Just had a thought on UI. Would it be better to put a settings page in the admin instead of keeping it in the admin bar? You can have a list of scripts and styles, with a checkbox or radio button to dequeue and a "View Asset" link. I can also imagine the "View Asset" link opens up a pop-up window with the contents of the asset in a textarea along with a link to the asset itself. Too far?

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 7, 2014

@jasonhoffman, by placing the Assets into the admin bar, the plugin is able to tell you precisely which assets are loaded for that exact page. Many plugins (and WP itself) only enqueue specific assets on pages where those assets are going to be used. A front-end asset may not be enqueued (and actually probably isn't enqueued) in the admin area.

Note that the Assets panel only appears for Administrator roles (and super admins in WPMU).

Thanks for taking a look and giving some feedback!

@fsylum

This comment has been minimized.

Copy link

fsylum commented Oct 7, 2014

I agree that plugin dev should offers some degree of control with regards to assets loading. Iinm, some plugins do offers this kind of control, by providing options to users to whether load the style or not.

However, I don't agree that providing the users CSS/JS to be copied and handled by themselves is the right route. As some points out, this is best handled by a dedicated plugin such as minQueue.

I also fancy on how Assetic handles assets loading, with few developers already build the plugin around it:

By this, you wouldn't need to worry about maintainability, plus every assets still can be handled by usual WordPress styles and scripts API.

@lumpysimon

This comment has been minimized.

Copy link

lumpysimon commented Oct 7, 2014

It's not a solution to this particular issue, but something that I think would help considerably, I'd like to see the 'Developers' pages on the WordPress plugin repo be opened up to allow plugin authors to add content to them using readme.txt.

Plugin authors could then use it to list all the assets their plugin loads to make it easy for another developer to un-enqueue them. They could also list any actions/filters provided, and anything else they think might help other developers/advanced users.

So essentially it's a one-page Codex for each plugin, so whenever I am working on a site and need to override or filter some stuff, the first place I'd check would be the developer page, rather than having to spend ages hunting around in someone else's code.

@JasonHoffmann

This comment has been minimized.

Copy link

JasonHoffmann commented Oct 7, 2014

@NateWr Oh got it. I guess that makes sense. But if you were going to be extracting various styles or scripts and bringing them into your own process you might want a list of all scripts or styles that are loaded on any page. But that gets complicated quick I guess. I wonder if there is a way to quickly get any scripts or styles that are enqueued on the front-end from the back-end?

Random thought. Maybe the thing to do is have users dequeue scripts and styles from the front-end, and then have a list of Dequeued scripts on the back-end. So if I select a couple and remove them, I can hop over to a list in the back-end and click a "View Asset" link for each. What do you think? The user flow gets a bit confused I think, but for me that list with quick links would be essential.

I'm certainly not an expert plugin developer, but I can try to help out if you need it. Maybe I'll dig around sometime soon and see if I can make that happen.

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 7, 2014

But if you were going to be extracting various styles or scripts and bringing them into your own process you might want a list of all scripts or styles that are loaded on any page.

If I understood @chriscoyier before, this is precisely what he doesn't like about auto caching and minification scripts. He wants granular page-by-page info on the assets so that he can concatenate his assets in the way that he knows best. I'm no performance expert, but I think that means he probably wants that front-page asset load to be as small as possible (rather than including every possible asset), and then he can decide on a page-by-page basis what's the most efficient way to load other dependent assets.

Think, for instance, about a separate forum section on a site, which might have a large CSS load that is unnecessary for optimizing that first-time front-page load.

I'm hesitant to add a settings page to the admin panel when one isn't needed, simply because I feel the admin panel is already a giant sprawling mess of menu items. A debug tool should be as un-intrusive as possible. But I did run across a case for having some kind of admin-area fallback -- with the plugin its possible to dequeue jQuery, breaking the plugin and the admin bar and basically making it impossible to requeue it while the plugin is activated. So it may be worth having some kind of "restore default" option, but that could even just be added to the plugin links page.

@theMikeD

This comment has been minimized.

Copy link

theMikeD commented Oct 7, 2014

If MinQueue gets the ordering wrong, it's not MinQueue's fault, is it? The enqueueing is done by the plugin and tf so are the prerequisites, so if it's an ordering issue, would that not fall back on the plugin dev?

@chriscoyier

This comment has been minimized.

Copy link
Owner Author

chriscoyier commented Oct 7, 2014

Noting Jason's article so it's referenced here: http://tidyrepo.com/plugins-and-front-end-performance/

@zoontek

This comment has been minimized.

Copy link

zoontek commented Oct 7, 2014

@NateWr is right, you can't access frontend assets in the admin area.
My solution was to scan plugins folders to find all JS and CSS files. It kinda works, but the list was really huge (with non-minified and minified versions of files).

I'm now working to put the existing plugin logic on front: https://dl.dropboxusercontent.com/u/4181800/lassets.png

@khromov

This comment has been minimized.

Copy link

khromov commented Oct 7, 2014

@NateWr

I think that means he probably wants that front-page asset load to be as small as possible (rather than including every possible asset), and then he can decide on a

I don't see this as a big problem. The assets are downloaded once and then get 304 not modified, so the performance penalty is the first download, where gzip helps a ton to keep the size down, and of course parsing the JS and applying the CSS. Modern JS engines with JIT shouldn't have any lasting performance issues from this approach.

@theMikeD

If MinQueue gets the ordering wrong, it's not MinQueue's fault, is it? The enqueueing is done by the plugin and tf so are the prerequisites, so if it's an ordering issue, would that not fall back on the plugin dev?

I have seen some edge cases where minified JS does not execute properly with MinQueue. Generally those issues stem from improperly enqueued files or non-standard code practices, such as not waiting for document.ready in jQuery.

I think the solution to these issues is that plugin devs integrate with MinQueue (or a similar plugin like BWP Minify) through filters - that way the devs could have perfect control and be able to test that their plugins work properly when using the minification plugin.

When working with MinQueue, I have been able to get a site down to just 4 requests:

  • 2 css requests (1 in header, 1 in footer)
  • 2 js requests (1 in header, 1 in footer)

In theory, this is what every site could optimized down to!

@khromov

This comment has been minimized.

Copy link

khromov commented Oct 7, 2014

@zoontek That plugin looks awesome, feel free to share it on GitHub! 👍

@zoontek

This comment has been minimized.

Copy link

zoontek commented Oct 7, 2014

By the way, if you want to grab my previous work (that list everything in the admin section), you can find it here: https://dl.dropboxusercontent.com/u/4181800/lassets.zip
Feel free to add two search inputs and release it (without it, it's really hard to use) .

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 7, 2014

@zoontek, I like the layout in your screenshot. How are you determining which plugins an asset is enqueued by? How would you handle situations where an asset might be enqueued by two separate plugins (eg - dashicons)?

No reason for us to duplicate our work if we have the same objectives. The only thing that strikes me as problematic about the minimal menu UI you're using is that you can't really provide any contextual information. My UI was quite a bit heavier, but it gave me an opportunity to point out important things about some assets (like those that may only be enqueued by the admin bar) and provide a full-path.

ui-screenshot

Perhaps similar context data or options could be available in your UI via a modal?

@zoontek

This comment has been minimized.

Copy link

zoontek commented Oct 7, 2014

@NateWr I'm just checking the plugin src to read the plugin folder, and only dequeuing plugins assets (you don't have to think about deps - you currently can't dequeue WordPress internal assets).

The path is available too, via a simple title: https://dl.dropboxusercontent.com/u/4181800/lassets2.png
The only utility i find for it is when a plugin enqueues two assets with the same name, but from differents folders.

@chriscoyier

This comment has been minimized.

Copy link
Owner Author

chriscoyier commented Oct 7, 2014

@NateWr - I tried it out and it's pretty sweet!

I did manage to get myself into a situation where I had to go into the DB and manually edit the options. I dequeued the Open Sans and it kinda screwed up the admin bar to the point I couldn't use the plugin anymore =)

But this should do the trick I think!

@theMikeD

This comment has been minimized.

Copy link

theMikeD commented Oct 8, 2014

@khromov

"I have seen some edge cases where minified JS does not execute properly with MinQueue. Generally those issues stem from improperly enqueued files or non-standard code practices, such as not waiting for document.ready in jQuery."

This also seems to come back to the original dev, right? It seems to me that creating a system like this is something that knowledgeable/responsible devs would use...but those aren't the problem IMHO.

It's a great tool to see what is being loaded in every page, no doubt. But if the author is not using wp_enqueu_*, that should be logged as a bug.

@nullvariable

This comment has been minimized.

Copy link

nullvariable commented Oct 8, 2014

I wrote a plugin that uses modernizr and lets you adjust any properly loaded WordPress JS resources in how they're loaded (either not at all, via standard plugin/theme config or via modernizr). It will also let you force load a resource. https://github.com/nullvariable/advanced-modernizr

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 8, 2014

I'm just checking the plugin src to read the plugin folder, and only dequeuing plugins assets

Ah, I see. You can dequeue things like jQuery. And I imagine that's probably something the performance experts would want to do, if I'm not mistaken.

I did manage to get myself into a situation where I had to go into the DB and manually edit the options. I dequeued the Open Sans

Hehe, I did add a big scary warning when dequeueing jQuery, so I'll add it to the Open Sans as well. I'll also add that "reset to default" option I was talking about.

@JasonHoffmann

This comment has been minimized.

Copy link

JasonHoffmann commented Oct 8, 2014

@NateWr - This is looking pretty good. I think you're probably right about wanting specific control, page by page. If anything, the back-end component is something that can be built out later.

Maybe as a simple fix, maybe it's a good idea to add the "View Asset" link to dequeued scripts as well. That way, even after they are dequeued, you can still easily go grab the asset and copy and paste it. Looking pretty solid.

Also, might as well tack dashicons css to the list of scary warnings, this can break the admin bar as well.

@AlchemyUnited

This comment has been minimized.

Copy link

AlchemyUnited commented Oct 23, 2014

@NateWr - Maybe I'm over-thinking it, but it might be helpful to have some sort of export / import capability. Some plugins are just notoriously sloppy in their enqueue'ing. Or perhaps there can be a library (XML?) of suggested settings for any plugin that has been encountered and add to the list?

@AlchemyUnited

This comment has been minimized.

Copy link

AlchemyUnited commented Oct 23, 2014

@webbelow said "The way I see it, all plugins should be designed for a perfect and clean HTML output."

How about a more view-y standard? Shouldn't / couldn't it be easy to do custom views for a given plugin? Especially for front-end facing, how many times have we heard "we like X and Y but can you change Z in the sidebar widget?" But changing Z more or less entails forking the whole plugin.

Sorry, if that just swerved a bit off-topic but if you can change Z then perhaps something needs to be denquue'd and then something else enqueue'd?

@NateWr

This comment has been minimized.

Copy link

NateWr commented Oct 24, 2014

Asset Queue Manager is now available on the WordPress.org plugin repository. Please report bugs and feature requests at the GitHub repo.

@jasonhoffman I got the View Asset link back in there for dequeued assets.

@jasonhoffman @chriscoyier I chose to change how I handle the warnings/fallbacks a bit. There's no big scary popup when dequeuing a valuable asset, but there is a discoverable fallback when you disable jQuery or something vital. You can reset at any time from a link under the plugin in your list of installed/activated plugins. There's probably room for development on this front, but I'd like to see if people actually use the plugin much before sinking more time into it.

@joeyred

This comment has been minimized.

Copy link

joeyred commented Apr 22, 2016

I have no idea how plausible this would be, but maybe it would be cool to offer the option to disable the included scripts & stylesheets (at least for the front end), and have the SASS, CSS, and JS available as a bower asset. Now, this wouldn't solve the problem for everyone, but it would allow sites with custom themes to bring the plugin assets in via bower and get it into their theme workflow so they can process it all as they wish.

Granted, even as I think of it now, I can think of all kinds of issues this could cause considering the varying workflows developers have. This also takes management out of the realm of WordPress and adds outside factors to influence 3rd party plugins and such. It could be hell to manage as the plugin developer and the end user. Especially so if the process gets too complex or convoluted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.