1.4?? already?

[calguy1000]

I've been committing some changes to CMS lately to solve a few problems that I've noticed, in anticipation of a contract that I may have coming up... and to solve a few problems of my own.

The major items
a) an improvement in stylesheet handling that will result in stylesheets being cachable on the browser
    this should result in a significant performance increase, and a decrease in server load on CMS sites.

b) Separation of Head and Body when performing smarty processing on a template
    this would allow you to set a smarty variable in a detail template, for later use in the header.
    so that you could adjust the page title or the meta description tag depending on what data is displayed in the page.
    also, you could include optional stylesheets, or extra javascript, and further optimize your pages.

c) I am considering (note: considering) either allowing stylesheet re-ordering, or implementing the 'Template Manager' module in the core (with some modifications) to allow for persistent, primary, and alternate stylesheets.

These first two items alone would probably be worth a 1.4, but we'll probably continue on, and fix a few bugs that are reasonable to fix, and throw in some optimizations and maybe a few other handy, but relatively easy to implement enhancements.    Like perhaps item c)

We're not planning this release for any time soon, these changes are going to have to go through at least one beta process. 

Although we really wanted to focus all of our efforts on 2.0 after the 1.2 series started, I no longer think that that is realistic.  I think that the 1.x series is going to have a long life even after 2.0 comes out.  and we might as well get used to it. 

2.0 is going to be such a large variation from the 1.x series, that there will probably be compatibility problems, and a significant amount of time will be required to stabilize everything.  We also can expect that most people aren't going to abandon 1.x immediately.  After the 2.x series comes out and gets stable, I can see the 1.x series slowly declining in usage, but never really dying.  Well, that's my prediction anyways.

So, yeah, there will be a 1.4, and it'll continue to improve performance, and implement new features that people really need or want, and that meet our target audience.

I just thought I'd keep you posted.

personal thought:  And now, that certain German person who can't play well with others, who felt it appropriate to base his own content management system on ours, and then criticize our work as inferior, who can't even bother to learn about version control systems,  and has alienated himself on no less than two other open source forums, will have more fodder for his psychotic rants.

[Dr.CSS]

I would love the style sheet reorder feature  ...

Oh that guy is so silly, what he is doing has always reminded me of a variation of his nick... pirate...

[calguy1000]

mark:

I'm torn now between just a simple re-order thing, or tearing out the 'layout' menu, and replacing it with a single menu item that handles it all in a module.  This module allows specifying persistent, primary, and alternate stylesheets... and provides a simple stylesheet switcher form.

There is significant code already written for this module, but some stuff needs to be done, and other stuff needs to be re-done.... so I'm torn.

Either way, I don't think it'd interfere with the current stylesheet stuff that's already committed.

Lets ask for public opinion.

[kermit]

I would love the style sheet reorder feature  ...

stylesheet ordering has been an open issue since well before 1.0 went gold.

another thing i'd like to see is some sort of popup or overlay calendar for date inputs in the back-end (core plus usable by modules). there's an old feature request for that one. inputting dates via pulldowns is soooo 1990's. 

[calguy1000]

well, I'm not gonna do the date popup thing because of the stupid styling issues that would give me nightmares forever... IE6, IE7, IE8... I get cold shivers even thinking about it.  there's a datepicker module that I started, and stoppped for just this reason.  Besides, being able to click a day, year, and month is in many cases alot faster than some stupid calendar thing, especially if it isn't feature rich enough... and then if you think that we don't require javascript for the back end....  nah, lets drop that.

but the question is... how to do the stylesheet thing, a simple re-order thing? or actually allow for persistent, primary, and alternate stylesheets?

[Dr.CSS]

What is the "persistent, primary, and alternate stylesheets" thing about?...

[baresi]

I hope this isn't taken as me being repetitious, negative, or anything like that...it is only a question or two

The possible performance improvements to listcontent are still possible or due at 2.0 but not before? And does the existence of 1.4 (and 1.3 and any others) delay 2.0?

[ZYV]

calguy, were you writing this calendar stuff on your own our you took someone else's like the Coolest DHTML Calendar? http://www.dynarch.com/projects/calendar/ - I've never had a single problem with it although it may seem a bit outdated.

P.S. What I would love to see in 1.4 is... remove any trailing bloat from the package. Let's see. First off, it includes a lot of useless SQL drivers, then, documentation, plugins and language files for many libraries used in the core. Then, for whatever reason many files have executable flag (notably languages) for no reason. In fact none of them should.

So the first thing I do after downloading a package is to delete unneeded languages (OK, this should not be done because we all have different needs), then delete ADO SQL plugins for whatever except mySQL 4+, then remove documentation, samples and plugins for all core libraries and finally changing all permissions to 644 (rw-r-r-, right?) and throwing .htaccess with deny from all all over the place like in plugins folder etc.

This way, my sites were not exploited when major security releases came out even if not upgraded at time. I predict that careless including whole packages may give a lot of problems of the same type than this postlet thing in future.

So, for 1.4 is it possible to revise default .htaccess disabling access literally to every unneeded folder and think of clearing up packages included in CMS? I know I can continue to do it my way. But every time it takes me some time. And most just wont go beyond the defaults even if security is concerned.

[calguy1000]

@mark, see this:  http://www.alistapart.com/stories/alternate/

[calguy1000]

P.S. What I would love to see in 1.4 is... remove any trailing bloat from the package. Let's see. First off, it includes a lot of useless SQL drivers, then, documentation, plugins and language files for many libraries used in the core. Then, for whatever reason many files have executable flag (notably languages) for no reason. In fact none of them should.

I would tend to agree with you, however it's not quite so simple....  I've deleted the sqlite option from the installer for now, but I'm not going to delete the drivers for it, or any of the other drivers, or plugins, etc. so that advanced users at least have the 'option' of trying out other databases or options.... from time to time this occurs... As well, deleting the extra files that we don't need just tends to make the problem of support worse.. 

I could expect if for example we deleted the french or spanish translations for phpmailer, that somebody before long (usually quite soon) would complain that they were no longer there. 

I know it's a pain, and the bloat can be quite extensive for sites that are only english, only use a few features, and want a small package to download and install.... but when you think about a larger community, some of this bloat serves us well.

There has been talk from time to time, of creating an 'english only' variant of the install, but we haven't gotten there yet... generating releases is already a cumbersome and time consuming process with enough steps to make it error prone.

Regarding permissions, yes, php files don't need the execute bit set... but IIRC it's also usually harmless to have it set.  php files with the execute bit can't be executed like a normal script, and even if they were, they could only be executed by a system command, or a shell on the server.... web servers open the file and 'read' it...  or am I missing something?

Regarding .htaccess files in each directory.... A single .htaccess file in the install root, or at the most in all of the directories directly under the install root should take care of all files on the install... I'll discuss this idea with Ted,

[Pierre M.]

Hello,

Public opinion ? Yeah, jumping' in : I welcome bug fixes and "minor" new features in "dot releases" be them called 1.3.z or 1.4.z. But I prefer 2.0's versionning, workflow, multilang and caching (and refined permissions model and and and...).

Have fun developing how you like it, I hope 1.y.z doesn't delay 2.0.0.

Pierre

[moorezilla]

Perhaps we could put together a how-to for removing the "bloat" for users who fall into this category?

I imagine that the majority of users would want a "just works" approach, but it would be great to have a how-to for people who want to tinker and remove what they don't need from a basic installation. Couldn't such a how-to be added to a README file in the distribution? Most people wouldn't read it, and the people who did would almost certainly be people who are in a position to be tinkering in there.

The question of 1.4, 1.5 etc., versus 2.0 is really a tough question when the number of developers is limited. Is this a case where the group could develop say 1.4 and 1.5 and then just produce security fixes for the 1.x tree and turn attention to 2.0?

If I had a vote, I'd say develop 2.0 over 1.x, simply because I'd hate to see the 1.x versions holding back the project. If the rewrite for 2.x will make the system significantly better and there will be an upgrade option for the 1.x users, I really think 2.x is the way to go. Drupal has this question pop up every so often, and they go with a "if we have to break backwards compatibility for significant progress, we will." This is not to say that we should do what Drupal does, but at least there's some opensource evidence for going in this direction.

[calguy1000]

Yeah, well we've already broken alot of things with 2.0.

Compatibility is probably going to be a problem, we're going to attempt some sort of compatiblity, but it may not be a 100% solution.  Personally, I'm not afraid of breaking backwards compatibility to accomplish the goals... but to me that means that the 1.x stream will at least have to be supported somewhat for a while until 2.0 catches up.  After that, I can see it slowly fading out.

I'm doing a 1.4 simply because I needed a few more things thrown in, and thought I'd take care of some other much wanted things while I was at it so that it because a worthwhile release.

Is this slowing up 2.0... probably, but not much.  There's only 2 of us working on it at the moment, and neither of us have as much time as we would like to donate to it.

[Caesonia]

mark:

I'm torn now between just a simple re-order thing, or tearing out the 'layout' menu, and replacing it with a single menu item that handles it all in a module.  This module allows specifying persistent, primary, and alternate stylesheets... and provides a simple stylesheet switcher form.

There is significant code already written for this module, but some stuff needs to be done, and other stuff needs to be re-done.... so I'm torn.

Either way, I don't think it'd interfere with the current stylesheet stuff that's already committed.

Lets ask for public opinion.

Calguy, probably becuase I don't understand exactly what you are trying to do, other than put the stylesheets into a module, I can comment as effectively as I might, but....

Since 2004 I have pretty much been a strong advocate for CSS, and it has represented 95% of all the presentation logic in my sites. While I screech over the conflicts with IE, I actually found very effective 'fixes' to get crisp simplicity. What that required though was for me to get deep down into the code itself.  I haven't really quite been able to do that with CMS made simple in the way I am used to, though of course, not writing the code from scratch makes it harder for me to feel comfortable about that.

What I would to do is to have that control back again. Any module that helps with that I am all on board with.  I have to admit the smarty combination in this didn't come out quite like I expected, and so though I had hoped to have that in depth handling, I haven't achieved it yet.

I hope that sort of gives an idea about where I am going with your CSS stuff.

[calguy1000]

The other thing I'm doing is improving the Module Manager/Module Repository so that it uses far less memory.  it's a bit more server load, but shouldn't be that bad.  and it'll significantly improve performance.

It will also be able to list only the modules that are compatible with the current CMS version, so that should eliminate a few more problems.

I am just testing to make sure that the Module Repository is backwards compatible, for people that haven't upgraded yet.