CMS Made Simple Forums

There will be alot of new classes, and objects in the core... and there's no way we can know (without setting up an environment, and then testing ourselves) what functionality will or won't work with PHP 5.1.x.

All of the new code in new code in the core, and modules will be written to support (and probably require) php 5.2.x.  If you think it's hard to get people to upgrade a system, try getting people to test every option, and permutation and combination of functionality on N different systems.  That definitely isn't gonna happen.

We do know that php 5.1.x is buggy in alot of ways, therefore the best bet is to start the process of getting your servers upgraded now.

Again... you may try to limp by, but your mileage may vary....

@tyman00 --- yes those are good points and I was just playing devil’s advocate  ... and to be honest I will be happy to have to install TinyMCE if it will help get the core in a tighter improved state.  But you said the big thing that I needed to hear which is that TinyMCE will be just as loved.  I'd hate to see a great mod like that die off.  still excited for all the upcoming changes...

Cheers
Jeremy

I think, that light WYSIWYG editor is a good idea. TinyMCE is still available as module - that is the point. TinyMCE is really powefull, but - as I can see from my experience - only small part of it is really used by customers. If customer / designer needs drop-down styles - he can install TinyMCE and customize the WYSIWYG toolbars fully free (for administrators and customers) till reducing full TinyMCE to the light-weighted features + styles drop-down.

It is difficult to say what is really needed and what not. I, personally, use cms_selflink extensively. Somebody needs styles, and another one cannnot leave without FilePicker. If you agree to the styles, you have to consider another voices as well. But if TinyMCE will live as module and will not be abandoned immediately after new release, it would be the best solution for everybody who would like to have sophisticated and fully customizable WYSIWYG editor.

OK So I'm probably flogging a dead horse here, but in defence of the style dropdown - it nearly makes all the other features of the full TinyMCE superfluous.

As an example from my workflow - I set up a class called:
.right_align_image {
float: right;
padding-bottom: 15px;
padding-left: 15px;
padding-top: 5px;
}

My users - yes it's usually a secretary or office junior - insert an image, highlight the image, choose right_align_image from the style dropdown and voilà - it looks great and they didn't need to know how it was done.
They don't need to know much more of TinyMCE after that.

Add a few more alignment styles and a few colour styles (they always want to change colours).

At least this way I get to control colour options and basic style options, which stops the technicolour rainbows a lot of secretaries like to impose on a carefully designed website.

I still think it's the key component in a a minimal editor.

I must be up to 4 cents by now.

Simon66

there is already an align left/right/center option in microtiny

the rest can be done with css

As an addon..

And your users have to 'know' to assign that class to the image when they add the image.
by simplifying the options, yes we're limiting the designer, but also limiting the end user in what they can use... and thereby limiting their ability to fu** things up.

adding a styles dropdown and then an 'html', and 'tables', and then 'paste from word', buttons (and more as has been asked)... we may as well just go with the full (oxymoronish) tinymce.  FCKEditor was bloated, slow, hard to configure, TinyMCE is bloated, hard to configure, though faster... we want non bloated, fast, and easy to use.

The answer is no... we won't do this.  People are already complaining about tinymce, and its difficulties, people are already complaining about the size of the package, and and the time it takes to upload.  We compromised in supplying a very limited wysiwyg editor.  Should we reconsider and go smaller?

and don't talk to me about kilobytes... don't wanna hear it.

Wow Calguy,
If I knew I was ruining your day this badly I would have STFU much sooner.

I'm sorry if I'm buggin' you...
Simon66

To answer the question about PHP 5.2 asked earlier.  Mainly, this decision was based on the gophp5 initiative a couple of years back.  However, since I had the php 5.2 features to work with, I used them extensively in a lot of different areas of the CMSMS 2.0 code base.  The main features I used were:

- Input filtering extension was added and enabled by default (modules will use this for parsing input parameters)
- JSON extension was added and enabled by default. (Because sending XML during AJAX calls is sooo 2005)
- Introduced DateTime and DateTimeZone objects with methods to manipulate date/time information. (HUGE deal -- the ORM uses this extensively)

Believe me...  I wish it could be PHP 5.3, but that would be totally out of hand.    There's some KILLER stuff in there.

I've said my piece and its created a sh1tstorm so I've given up trying to talk sense into the devs anymore.

I'll do what Sonya said and waste time configuring the full version of TinyMCE every time I set up a site.

I'm not against cutting down the bloat that is TinyMCE, I am against using outdated and blatantly incorrect methods of styling content. Its not a designer vs developer issue, its an issue of creating clean and sematic html without any forced visual information in it. Simon66 demonstrated a perfect example of use of a class to align images (.right_align_image).

What can be confusing about a style dropdown that has a left and right align image?

I'm not advocating to start putting in all the things people think they really need in the microtiny, but I would have thought styles were an important way of going forward and teaching people to use existing css classes, not inline styles.

I've had enough of this argument, because its obviously falling on deaf ears.

geeves wrote: I've had enough of this argument, because its obviously falling on deaf ears.

It is not about deaf ears. It is just about what people need To keep HTML clean, I do not only need styles dropdown, but "paste from Word" and "cleanup messy code" as well. These buttons are very important for me. 

geeves wrote: .... and waste time configuring the full version of TinyMCE every time I set up a site.

I always configure TinyMCE, I have saved a set of common buttons for toolbars and just copy them into configuration for each installation.

Generally, every deleted function in CMS Made Simple is painful. Love hurts But sometimes there is just overkill on usefull functions. You use them because you know how. The most users (administrators on their own) have never seen the configuration of TinyMCE. And if they find TinyMCE admin "by accident" they are just scared.

I will miss TinyMCE as well, but if it will be supported as module I will be happy

If you don't like the MicroTiny you can still configure your own Tiny as you wish based off of TinyMCE and export the XML file in Module Manager. Then in future sites install your version of Tiny with the XML file you exported. The thing is if the list would have been included and other buttons would have been included then people would have been complaining that it is still too bloated. You can't satisfy everyone, it is felt the current setup will cover the needs of the high majority. Those that want the drop down or this button or that button should be fully capable of making their own changes to TinyMCE (as they currently are) or MicroTiny.

Finally there will be no need to miss TinyMCE as there has been plenty of support shown (even from some devs) to keep that module alive. We aren't trying to cripple everyone, just offer a simple editor that will cover the majorities needs. If we were trying to cripple the process, TinyMCE would have a death warrant not a promising projected future.

Looks like I really stirred it this time... 

Dr. CSS wrote: Looks like I really stirred it this time... 

Yeah ya did wasp nest poker... looks like you found 5 other supporters of you thought thou...

+1 to have the style drop-down menu included, sorry!

I'm 100% behind the stripped down WYSIWYG, absolutely fantastic. In terms of client support and training, this makes things much easier. However, losing the style drop-down is a decision which is very unfriendly to the support of standards and clean and consistent markup.

Example 1: Tables

When inserting content, tabular data is very common. It might be a schedule, timetable, pricing grid, or a reference table of chemical compounds. Whatever. Over a certain width, and usually if the table has 4 or more columns, the human eye struggles to read the data accurately. Thus, zebra-striping is required on alternating rows. To do this we create two CSS classes (.tblRowOdd and .tblRowEven, say). Using the tag selector at the bottom of the WYSIWYG, a content editor can select the TR and the apply the style. Easy, simple, clean.

Example 2: Non-standard headings

Although we always try to create clever CSS selectors to set heading (H1, H2, H3) appearance based on context/location, it's not always possible. On occasion you might need to set an additional class on on a heading -- perhaps on a page about trees and this class will give you a nice leafy background image and appropriate padding around your heading. The heading cannot be selected just by clever CSS since it exists in the same DIV as all other page headings. You must set a custom class on the heading.

Example 3: Fancy list types

Not all lists are the same and your standard CSS selectors can't always account for quite common situations. For example, it's not just that the client wants trivial things like one bulleted list to have orange bullets and the other to have purple hearts, sometimes the actual layout needs to be different (numeral type, padding, background, and more). A drop-down style selector makes this easy.

Example 4: Image placement

I know it was mentioned (and dismissed by Calguy), but when you're making beautiful websites, which we're all trying to do, a simple align right + padding doesn't cut it with in-line image placement. You want margins, padding, borders, background colours, the whole lot. Being able to attach a simple class to an image is so easy and neat. It would be a real shame to lose this.

Please listen to your users and re-consider adding the style selector as a standard feature to CMSMS' editor!

I've read through this thread again and whilst I see the logic behind the decision, I think the DESIGNERS here are seeing something the DEVELOPERS are not. I think it goes something like this:

Current problem: TinyMCE is bloated and confusing for end-users, thus most installs of CMSMS demand a custom configuration of its toolbars.

The plan with 1.7: A stripped back WYSIWYG (MicroTiny) is welcomed, I believe, by everyone.

The result: MicroTiny not including the style drop-down demands that TinyMCE be installed and custom configuration of its toolbars is still required.

Therefore: We're actually in a worse state because not only do we -- in most cases, I believe -- need to create a custom toolbar configuration for TinyMCE, we actually need to rip out the standard editor first!

And a further therefore: You will have most installs of CMSMS using the non-standard editor and thus support becomes more difficult.