leeturner wrote:Well, technically the nightly build should use the same build process as our normal build for our release process ...

I'm going off topic here, but wow that's the answer to Yabs' "upload_files" thing that caused so much angst. I have no idea how tblue is doing the nightly build, or what it takes to make a release inside LP, but what I'm thinking right now is the two processes should be identical. In other words, when it is time to make the next release we should be able to wait for the next auto-build, then tell LP to package a release and somehow get the exact same product.

Branch trunk if is hasn't been branched yet, pull updates otherwise. No merge conflicts should happen here as nothing has been changed locally. In other words, we create an exact copy of trunk and keep it up-to-date, checking for updates on a daily/nightly basis.

Bazaar has a feature that allows one to "export" a branch, that is, to zip it up while omitting all the control files and directories that Bazaar needs to keep track of changes etc.

The command to export a branch is, well, "bzr export". Maybe TortoiseBZR/Bazaar Explorer allow one to use that command with a GUI as well?

bazaar explorer has a generic way to run a command. I told it to run export and it told me what arguments I could make and what I had to make. One thing I couldn't do was get it to export from LP to my computer, which makes sense because it is a local control tool. That is to say it's job is to be "explorer on my windows pc that knows how to talk to LP". I suppose it may be possible, but at this exact moment I'm seeing explore as a shorter way of doing "copy the quam-plures folder, rename to the next client's domain name, delete .bzrignore, delete /bzr/, delete out the bits I know I won't use for this client, copy results to another folder where I can add bits I know will need adding". I should be able to export the core twice then tinker on each copy as per my model.

BTW I do 2 copies so upgrades to core can be done first to my core, then to client's clone where bits are missing but not added, then to client's actual files where bits are added but not missing.

Anyway the end result is that the GUI is for people like me: it allows for easy minimum interaction with limited opportunity to break something

I haven't read all 5 pages yet but yes we do need to compress all the CSS files into one big file. Except the 'reset' css of course.

For some reason, browsers have a limitation on how many css files a document can call (it's counting @import and link rel). When I was experimenting with something else, I kept on hitting that limitation. I ended up doing embedded stylesheet to give enough room for other stuff that I have no control over (like some third-party calls, which also counts, gah).

If the limit is reached, any other non-embedded CSS calls will be ignored by browsers. I haven't ran down on the templates I have on my localhost yet for those - I'll be switching to embedded stylesheet or merge a couple.

Maybe we can keep just two: reset stylesheet, and re-stylesheet. Then the template only have 1 stylesheet, so that makes 3 stylesheet @import and/or <link rel>.

Laibcoms wrote:I haven't read all 5 pages yet but yes we do need to compress all the CSS files into one big file. Except the 'reset' css of course.

We have no reset css file, but still I see no need to jam them all into one file.

Getting rid of @import was extremely easy ... on the public side. I think in QP5 I still use it on the admin side. When doing that I found that quite a few bits are exactly duplicated in files, which is wasteful. So that needs addressing too. BUT getting rid of @import is easy.

The thing we should look at is how to get rid of files, and one really big tool to do that would be to assume we will not share css files between public and admin. So on the public side we would have reset (maybe), blog_base, item_base, and template_specific. On the admin side reset (maybe), core_admin_style, admin_template_style. Stuff would be duplicated across them, but they wouldn't be sent to the same visitor so the "waste" in actually in how we manage the styles going forward.

But yep, I think it's better to separate public and admin. I think the public side is where we'll need to minimize the css files (@import and link element) since that's where the blog's load time matters. (For the admin, well the admin[s] can live it with…)

As for the reset css, since we don't have it, then I think we can leave it out. I actually am not a fan of it, especially when the reset is global: * { } Template authors can just add it themselves before the @import/link call of qp's default public-css file.

EdB wrote:Getting rid of @import was extremely easy ... on the public side. I think in QP5 I still use it on the admin side. When doing that I found that quite a few bits are exactly duplicated in files, which is wasteful. So that needs addressing too. BUT getting rid of @import is easy.

Ed, did this ever get merged in ? I can't remember now. I am just getting back into a bit of QP play after a load of work related bit meant I had no time and I am just trying the whole page speed thing on my sites.

I have just added bits to my .htaccess file to enable browser caching using expires headers which I think you did also. Did that get merged in also ?

What was the tester for that? I was using a chrome plugin called pagespeed or some such, but it gives a different response format. Now all I do is point out to potential clients that theirs probably sucks and mine rocks

(pagespeed doesn't care about bandwidth or server speeds or anything like that - it'll score the same whether you are using dialup to talk to a server or checking a page on localhost.)

As the pic shows, it uses yslow and pagespeed. The things I added to the .htaccess file made a big difference so I was wondering if we should add them to the sample.htaccess file that we ship with a release.

Then of course there is all the bits you were looking at with regards to @imports.