CMS Made Simple 2.0 (not 1.7) is in development

[Simon66]

Thanks for the heads up about all the yummy goodness of 1.7. Drooling has commenced.

One small question though...
Will 1.7 allow the Smarty {include} to be used in templates, to include template bits like 'headers' and 'footers', for leaner templates with less repetition?

Simon66

[geeves]

Why use {include} when there is {global_content}?

[Simon66]

If I allow my client access to Global Content Blocks I don't want them to have access to bits of the template.
I would prefer all unchangable template elements to be kept in 'templates' which only designers and developers have permissions to access.

I do use a GCB as the footer on all of my sites, but if I try to export from the Theme Manager it leaves out the GCB, which is another reason not to use GCBs more often in templates.

GCBs are brilliant for content, but I like to keep content and templates separate.

Just My 2cents.

Simon66

[EDIT] I also use them for editable content in templates, just not for template elements.

[faglork]

+1 vote for style drop down. Style dropdown is much MUCH more important than alignment tools which just add inline styles to elements to align them. CSS classes should be used for things like alignment of text and images:

Inline styles are never okay. The goal with (x)html / css development is to separate content from presentation. Well, let's start trying to make that separation a goal for v1.7.

++ ... a clean separation  is IMO very important. 

Cheers,
Alex

[Solutic]

 - We will be requiring PHP 5.2+, and forever breaking PHP4 support.

Hi,

First of all, thanks for all this excellent job!
I have a question, will CMS MS be compatible also with PHP 5.0.0 and more ?
I have some website with some older version of PHP 5

Thank you for the answer!

[calguy1000]

@Solutic
CMS 1.7 will support php 5.2+

@others
The style dropdown was voted out of microtiny intentionally.  it won't be in.

[geeves]

What possible reason would there be NOT to include the style dropdown? I think a better explanation than 'it got less votes than something else' is warranted.

Inline styles are fundamentally wrong and against best practices. It is imperative that there is a clear separation between the sematic and the aesthetic.

I really hate having to use TinyMCE in the first place, but now we're on the verge of having something clean and simple available with the advent of microtiny and its already being stuffed up!

[Simon66]

I have to agree - the styles dropdown and the SelfLink button are the standout features of TinyMCE. They really make things easy for my clients and staff.

Will begging, pleading and fawning make any difference?

Simon66

[I do understand that I'll be able to use the full editor as a separatre module, but the microtiny is such a good idea, that with styles it would be everything any of my clients would ever need.]

[Sonya]

Will begging, pleading and fawning make any difference?

My guess - there are more developers in the dev team and few designers. Developers are not interested in designer stuff but programming functions. Therefore designers cannot push something by simple voting and are always overruled

[calguy1000]

My guess - there are more developers in the dev team and few designers. Developers are not interested in designer stuff Smiley but programming functions. Therefore designers cannot push something by simple voting and are always overruled

No, it's about focus on our core intentions:
a) separating content from design as much as possible
b) creating a tool where customers (the average receptionist, or spouse) can easily update content without messing up the look and feel of the site.    Edit:  and without having to memorize a bunch of 'rules'
c) creating a small easy to use, lightweight editor.   We wanted to get rid of a wysiwyg all together, and just go with a basic html or bbcode editor.  (something like the default html editor in wordpress) but we compromised.

A small editor with just a few limited options (bold/italics/underline, h1 thru h5, code and blockquote), and a properly configured stylesheet and template will allow the average end user to do 95% of what they need to do.

Designers should know HTML, and CSS, and know about the concept of separating design from content.  If they need a wysiwyg with 30 block styles in the list so that they can layout a page properly, they need to go back to school IMHO (I've edited a few sites built by other people where this was the case, the designer didn't have a real clue about what he was doing).   Otherwise, they can install and configure the full tinymce and muck along like they always did.

[Pierre M.]

Hello all,

thanks for the news about 1.7dev.

No, the javascript calls will not AUTOMATICALLY be included in every frontend page.  There'll be a fair bit of stuff in there, so most people wouldn't want ALL that javascript included automatically.  So you'll either have to include it manually with the appropriate tags, or we may provide some funky smarty tag method for including things... we haven't thought that far yet.

I like this light way. I always test sites with JS disabled (on the public side). Since CMSms 0.x we can make JSfree sites and I think this possibility is a strength of CMSms. We can make the templates we want, no JS mandatory.

1) We'll be removing alot of...
2) We plan on completely removing...
...
4) We're permanently removing some of the old plugins from the core...

The shorter the lighter the better : less corner cases, less side effects, less bugs

we're gonna remove TinyMCE from the core install (it'll be available as an addon) and replace it with a stripped down version.

Welcome microtiny, small is beautifull.

Also, we're replacing the printing module with a stripped down version (no buggy/limited/huge pdf printing).  the regular printing module will be available as an addon.

Call me a fanatic : a media="print" CSS is right enough for "core". People wanting something more complicated, less webby or PDF generation are free to bloat their install (and upgrade processes) with modules.

CMS 1.7 will support php 5.2+

OK. Will it support 5.3 ? Is 5.2+ 5.2.z <= N < 5.3 or 5.2.z <= N <= 5.3.t ?

The style dropdown was voted out of microtiny intentionally.  it won't be in.

Cool. People wanting something less simple can still use the current full Tiny.

Pierre M.

[JeremyBASS]

My guess - there are more developers in the dev team and few designers. Developers are not interested in designer stuff Smiley but programming functions. Therefore designers cannot push something by simple voting and are always overruled

No, it's about focus on our core intentions:
a) separating content from design as much as possible
b) creating a tool where customers (the average receptionist, or spouse) can easily update content without messing up the look and feel of the site.
c) creating a small easy to use, lightweight editor.  We wanted to get rid of a wysiwyg all together, and just go with a basic html or bbcode editor.  (something like the default html editor in wordpress) but we compromised.

A small editor with just a few limited options (bold/italics/underline, h1 thru h5, code and blockquote), and a properly configured stylesheet and template will allow the average end user to do 95% of what they need to do.

Designers should know HTML, and CSS, and know about the concept of separating design from content.  If they need a wysiwyg with 30 block styles in the list so that they can layout a page properly, they need to go back to school IMHO (I've edited a few sites built by other people where this was the case, the designer didn't have a real clue about what he was doing).  Otherwise, they can install and configure the full tinymce and muck along like they always did.

For what it's worth, thou I highly agree that any WYSWYG editor should never be used for page layout, but I would say that the drop down does allow the on setting up all the systems for those "the average receptionist, or spouse" to give them something like a color option, or a table... IMHO we should stay with what we have now just reduce the default options to match what is being suggested as the new editor.  It’s nice and getting better every time…  Now after all if someone doesn't know how to use a word processor then they have more issues then what will occur from trying to work CMSms...  As I understood it this package was never meant for the average receptionist or spouse to be doing everything.

Few Humble opinions from a guy playing dev and designer for many clients:
A.)the average receptionist, or spouse is the end user the works on most of my setups.
B.)They love what is setup now, and love CMSMS
C.)If we see a change to the new tiny then I would think there will be many like me needing to do more work to put the “bigger” tiny back in
D.)+80% of the end users I serve find the editor now much like the word processor they use now which is a big plus

My IMHO I think this change would go against the target market, but if I’m wrong and the target market is not web masters as previously stated and has shifted to the target of the average receptionist or spouse then I’d think that this is a great solution for them and more work for ones like me.  Just My2Cents and vote if had…

Cheers
Jeremy

[calguy1000]

@pierre, yes CMSMS 1.7 will support PHP 5.3

I'm doing my dev work for CMSMS 1.7 in PHP 5.3 with sqlite

[moorezilla]

I know the the php version officially supported by 1.7 will be 5.2+, and I'm not suggesting this be changed.

I'm curious, though... are there things planned for 1.7 that you guys know already won't work with php 5.1x, or are you just looking even further down the road? I have some Red Hat installations which only support php 5.1.x, and though it's probably possible to upgrade the php on these boxes, doing so won't be supported by the agreement we have... yada yada yada. If 5.2+ is just needed for the module manager to work, or something easily circumvented like that, I'd just uninstall the module manager or other offending piece, so if there are just particular, easy to identify things in the planned 1.7 that won't work with php 5.1.x, a list would be really helpful to me and probably to other people in a similar position. I know the best fix is to just use a dist that supports php 5.2+... I know... I know... but it's amazing how difficult it is to get people to update/change such things at times, so I need to find a workaround if possible.

CMSMS is great, btw, and the contribution is much appreciated!

[tyman00]

Few Humble opinions from a guy playing dev and designer for many clients:
A.)the average receptionist, or spouse is the end user the works on most of my setups.
B.)They love what is setup now, and love CMSMS
C.)If we see a change to the new tiny then I would think there will be many like me needing to do more work to put the “bigger” tiny back in
D.)+80% of the end users I serve find the editor now much like the word processor they use now which is a big plus

I'm not going to go into the drop down menu discussion. Most of what I believe has already been said.

Just wanted to ease some concerns for you JB. From my experiences I think the majority of people that will be using the WYSIWYG are only going to want to do some minor changes to the content. Bold, Italicize, Align, Link, Image. No need to inundate them with loads of other options confusing them and likely leaving them open for a chance to wreak havoc on your template.

However, yes there are some times when the regular tiny is needed. It really is no different than installing another module (be it from MM or XML import). It will reduce the Core download size as well. Keep in mind that MicroTiny and regular Tiny can both be installed so you can allow different users on each site to have different functionality based on their editing duties. Because sometimes you just don't want that one certain secretary to be able to turn every other line red and green at Christmas time.

Also, don't worry regular Tiny is more likely to receive more love than MicroTiny in the future because of Micro's basic functionality so it won't get left by the wayside. I feel following the KISS mindset with the Core download and providing the option to go bigger is a good step forward.

The other option is to ship it without any WYSIWYG and allow each developer to decide which way they want to go with available WYSIWYG modules in the forge. (IMHO, the better option... since we all have varying ideas for ideal setups)

TinyMCE
MicroTiny
FCKEditor
Wyzz Editor
HTMLArea
Spaw
DL Suite: Spaw2
Xinha
widgEditor
DojoEditor
InnovaStudioLoki
openWYSIWYG
WYMEditor


And for those of us control freaks that want to use syntax highlighters:

EditArea
DL Suite: EditArea
CodePress
DL Suite: CodePress
CodeMirror