search

s9y / Serendipity

A PHP blog software
https://s9y.org
BSD 3-Clause "New" or "Revised" License
208 stars 88 forks source link

Combine/minify backend CSS/JS #189

Closed yellowled closed 10 years ago

yellowled commented 10 years ago

We need a way to combine and minify CSS and JS in the backend. (I'm not aware that we already have this kind of mechanism. If so, I don't know how to use it. Note that this issue was originally part of #85; I moved it to a seperate issue for clarity.)

Ideally, it would work this way:

  1. any CSS and/or JS required by a plugin's backend section is emitted by the plugin
  2. any CSS and/or JS required by a backend theme is emitted by the backend theme
  3. users can add custom CSS (maybe also JS?) using e.g. a user.css to easily override properties of the backend

These three steps (including JS/jQuery plugins required by e.g. any given plugin's or theme's JS) should be combined (in that exact order) in one JS file (serendipity_editor.js seems appropriate). That dynamically generated file should be minified for better performance, which means strip comments and unnecessary whitespace.

For additionaL_plugins we need to keep in mind that we will need different CSS and maybe JS for 1.x and 2.x.

yellowled commented 10 years ago

Once this is implemented, we would also be able to revisit all backend tpl files (also for plugins in 2.x) for inline CSS and JS. Those should no longer be necessary with this mechanism.

garvinhicking commented 10 years ago

I don't think this will be possible, or beater: feasible. Plugins can dynamically inject their code, so it is required that they are executed time and again. CSS and JS can change depending on login state, other external variables etc.

We might need to add a new hook like css_minifieable and js_minifieable, and adapt each and every plugin to support those new hooks.

This is DEFINITELY something that belongs to "Future", and not RC or Release milestone.

yellowled commented 10 years ago

Plugins can dynamically inject their code, so it is required that they are executed time and again.

I don't understand that and/or why it presents a problem.

CSS and JS can change depending on login state, other external variables etc.

Why would it? This is just for the backend CSS and JS, not frontend. The login state for a backend section is always “logged in”, otherwise it's irrelevant, isn't it?

This is DEFINITELY something that belongs to "Future", and not RC or Release milestone.

In that case, it will be next to impossible to fulfill #149.

We need a way to emit different CSS for the backend sections of those plugins, otherwise we'd have to put them all in templates/2k11/admin/style.css which would bloat that file significantly.

garvinhicking commented 10 years ago

OK I think I have missed this "backend" terminology. Maybe it's more feasible now, however I'm lacking ideas on how to implement this. Writing a static file is really against our whole dynamic approach.

yellowled commented 10 years ago

We have had this in mind ever since we started building this new backend. I'm pretty sure @onli has ideas for it. I might as well not have expressed the whole process very well. I guess this is a devTalk topic (which is why I moved it to a seperated issue in the first place). :)

onli commented 10 years ago

There are two methods for minification of CSS/JS I see so far:

  1. Embed all the code via the css/js-hook, and add a minificator function around that. That would have to be benchmarked though, but I expect it should worth it on typical setups. The minificator function could be deactivable.
  2. There are approaches using smarty, like in http://www.meetup.com/oc-php/messages/boards/thread/4106842?thread=4106842

For 1 it might be helpful to always embed all the needed JS into all the backend, than we can easier use the JS-hook of the backend template.

Both are feasible for RC or the next beta in my eyes. We can talk about this ofc.

yellowled commented 10 years ago

Minification would be nice to have, but we could probably live without it. The combining and especially switching for 1.x/2.x are much more important.

However, I really think we should address this in the devTalk. I'm not sure I did explain well why and how we need this.

garvinhicking commented 10 years ago

In devtalk we discussed that emitting specific CSS and JS for plugins can be handled just like the smarty markup with a version switch. Once a plugin is found that requires different CSS/JS we can use that as an example.

The other issue is to combine all 2k11 JS files into one big, grunt-ified file and embed that in index.tpl, thus removing all Githubissues.

  • Githubissues is a development platform for aggregating issues.