Better CSS

driz · 2009-07-26 02:37:42

I’m not really sure why CSS in Textpattern relies on the separate css.php file that is included in the core files, but even more so that it is called actually on the page where your css is, eg. /textpattern/css.php?n=mystylesheet

What I think would really make things better is if natively Textpattern had all CSS files stored in the database like they are now AND also saved to a directory like rvm_css, and then have them called them in this manner /?css=mystylesheet if being called from the DB and /css/mystylesheet.css if called directly from the static version on the server. Perhaps even have an option in preferences to turn on the static files if certain users dislike it?

In addition to this, native support for JavaScript files could also be a good one, or perhaps the ability to incorporate JS files using a plugin based on the same concepts brought forth for the CSS.

This is something that has being bothering me for a while, and would love to see implemented, as it would be much cleaner. Your thoughts?

TheEric · 2009-07-26 03:25:37

There’s lots of stuff that bothers you about TXP evidently.

colak · 2009-07-26 04:33:21

theming is coming up Cameron

jakob · 2009-07-26 08:51:31

Saving to both the database and a file introduces a level of redundancy and may also introduce confusion because they are in two places (where to edit, via ftp, via interface…, make sure synced). But essentially you can make the decision yourself based on how you want it (I’m often adapting the setup to fit the needs of the respective site and users):

Use files and put them in a /css/ directory and call them directly.
Use rvm_css, which was conceived for just this purpose.
Add an entry to your htaccess to make links formed as /css/ call /textpattern/css.php?n=mystylesheet.

Last edited by jakob (2009-07-26 08:51:53)

wet · 2009-07-26 11:04:36

driz wrote:

What I think would really make things better is if natively Textpattern [..] have them called them in this manner /?css=mystylesheet

Care to explain in what regard this particular way of constructing the CSS’s URI would be beneficial?

keith · 2009-07-26 13:33:06

I was wondering the same thing: that’s “better” about this implementation?

Kinda seems like change for change’s sake to me.

ruud · 2009-07-26 13:43:40

I’m guessing consistency, because apart from static things like images, everything else is using index.php. The reason for having the separate css.php may have been efficiency. Why load a huge chunk of code, when only a small bit is needed for serving CSS.

driz · 2009-07-26 18:32:48

Well consistency is one factor for having better URLS. Second linking to a file inside the textpattern folder exposes it and makes it awkward if you want to change the name of the installation.

ruud · 2009-07-26 18:37:48

SVN currently has css.php outside the textpattern folder, alongside index.php.

driz · 2009-07-26 18:42:14

ruud wrote:

SVN currently has css.php outside the textpattern folder, alongside index.php.

What is the purpose of having the CSS.php file at all? Why isn’t it part of the actual core files? Their are two CSS.php files as well one outside TXP and then one inside TXP which link to each other.

wet wrote:

Care to explain in what regard this particular way of constructing the CSS’s URI would be beneficial?

Just cleaner and fits in better with the URL schemes produced by Plugins. Its better IMO to be just simply dynamic using the ? rather requiring the linkage to the actual php file(s) used for the creation of the CSS. ExpressionEngine uses this very same idea for the exact same reasons.

Last edited by driz (2009-07-26 20:02:18)

artagesw · 2009-07-26 20:08:38

css.php was moved outside the textpattern folder to enable the multi-site capabilities in 4.2. The css.php inside the textpattern folder is for backward compatibility, I believe.

driz · 2009-07-26 20:32:30

My confusion here is that CSS to rendered using <txp:css n="lorem" /> so if someone was to move the CSS.php file, their would be no need to worry about backwards compat because the linkage is left in the hands of TXP and NOT the user creating the link themselves right?

But I still dont understand why their is a separate file for PHP? Why is the code for it not included with the rest of code for images/links/files/pages/sections etc.

Bloke · 2009-07-26 20:51:32

imho, this argument is eclipsed by the fact the CSS is stored BASE-64 encoded in the database which a) bloats its size, and b) adds time to the CSS download process as it is decoded.

rvm_css is a stock component of all my sites because I like serving stuff from the file system: it’s piggin’ quick in comparison. For some, this isn’t a big deal so to leave it in the DB is fine and having it in two places at once on a stock install — as jakob pointed out — might just make things unnecessarily complicated.

As for the css.php, I’m with ruud here; it’s gotta be quicker to load that tiny bit of php than the whole of index.php, which probably helps to compensate for the fact the CSS has to be decoded from the database ;-) But perhaps the way the URL is presented could be better out of the box, I don’t know. Again, there are options if you wish to present a unified URL scheme to your visitors (gbp_permanent_links or .htaccess) and I get your argument for why it should be presented like that by default. The question is whether it can be unpicked in the core from all the legacy code… and whether it needs to be. My guess is that since it’s not been addressed by now, the chances are there’s a reason why it’s the way it is.

Of course, it could be that nobody’s really paid much attention to that corner of the code before!

driz · 2009-07-26 21:00:03

Well if your using rvm_css you’ve got two copies anyway :/ I dunno I can’t see a problem with it being stored in the DB and then allowing other people to cache it in a folder from the admin preferences pane if you desire (in other words its not on by default) therefore it wont be in two places on stock default, ONLY after the user has chosen to do so.

But for me this makes perfect sense the DB version is the main one and then the cached version is the one that could be loaded if so desired. I just feel this should all be built in. And legacy systems should work fine with it, as nothing is really changing, your still using the same TXP tags, so ALL sites will still work the same, all coming from the DB, but those who want the cache version too, that will just work the same as rvm_css but natively, so when the option is set to YES the <txp:css /> will serve it from the cache file instead of from the DB!

Also coming back to the CSS.php file, are you not already using the index.php file for the page rendering and articles? so why not have the CSS use it as well?

Bloke · 2009-07-26 21:30:41

driz wrote:

Well if your using rvm_css you’ve got two copies anyway

Yep, my choice though and I’m a geek so I don’t mind :-)

I would very much like to have the option of CSS in the file system and/or in the DB natively. Treating the file system version like a cache makes sense to me as well. But again: I’m a geek not a designer so this sort of thing is on my radar. Might not be for people of a non-cody mindset?

Any road, will have to see what’s possible. I’d rather see if it’s possible to demangle the BASE64 thing first so plugin authors can offer simpler CSS tools (for example, searching them from smd_where_used without going through the coding pain of treating it differently to all other admin-side data!) Probably more important than what a URL looks like!

btw, xPattern’s first patch was to essentialy roll rvm_css into the core.

coming back to the CSS.php file, are you not already using the index.php file for the page rendering and articles? so why not have the CSS use it as well?

*shrug* only been in the job a week. There’s a whoooole lot of code to grok yet…

Last edited by Bloke (2009-07-26 22:04:24)

Textpattern CMS

Textpattern CMS support forum

#1 2009-07-26 02:37:42

Better CSS

#2 2009-07-26 03:25:37

Re: Better CSS

#3 2009-07-26 04:33:21

Re: Better CSS

#4 2009-07-26 08:51:31

Re: Better CSS

#5 2009-07-26 11:04:36

Re: Better CSS

#6 2009-07-26 13:33:06

Re: Better CSS

#7 2009-07-26 13:43:40

Re: Better CSS

#8 2009-07-26 18:32:48

Re: Better CSS

#9 2009-07-26 18:37:48

Re: Better CSS

#10 2009-07-26 18:42:14

Re: Better CSS

#11 2009-07-26 20:08:38

Re: Better CSS

#12 2009-07-26 20:32:30

Re: Better CSS

#13 2009-07-26 20:51:32

Re: Better CSS

#14 2009-07-26 21:00:03

Re: Better CSS

#15 2009-07-26 21:30:41

Re: Better CSS

Board footer