And Leevi’s extension requires no programming at all…simply install, configure and away you go, no more meddling necessary.

Erin Dalzell - 17 April 2009 09:07 PM

And Leevi’s extension requires no programming at all…simply install, configure and away you go, no more meddling necessary.

Not always:

Derek Jones - 07 August 2008 09:36 AM

if you’re expecting a first party solution to getting multiple third party scripts to play nice together, you’re going to be waiting a long time.

http://expressionengine.com/forums/viewreply/440948/

This WYSIWYG extension (LG TinyMCE) developed by Leevi has a conflict with ExpressionEngine.

So, programming is a must for some official EE extensions.

P.S. I think that (above; LG TinyMCE) was a nice example of the mentioned approach:

“Well, there was a guy some days ago… We believe he has built some kind of coffee-making machine… or something else… It’s in the back room, you can go there and try to use it… May be it’ll make some coffee…”

sigork - 18 April 2009 01:31 AM

This WYSIWYG extension (LG TinyMCE) developed by Leevi has a conflict with ExpressionEngine.

So, programming is a must for some official EE extensions.

Care to share some details, solutions etc. ???

Cem Meric - 18 April 2009 02:04 AM

Care to share some details

http://expressionengine.com/forums/viewreply/441356/

Cem Meric - 18 April 2009 02:04 AM

solutions etc.

I described the problem to Leevi. No solution.

I’ll preface this by saying I’m a huge fan of EE, and a real evangelist for it within my company.

I think Leslie’s comment earlier was correct: this thread serves to remind us that different CMSes have radically different philosophies to how things as basic as URLs work. That’s important to note, as the community of people embracing EE continues to grow.

—

Many mid-weight CMSes have a primary display method associated with each content node (think “entry”). That means you permalink to the node, and the CMS figures out the display template through attributes of the node. Often the links are held internally as node UUIDs, and only translated into URLs and HREFs as the page is rendered (very much like EE’s upload directories).

But EE relies on the URL to assert the disply template. It’s actually a very flexible approach and one of EE’s strengths. But I’ve seen other people who have worked on mid-weight CMSes find this perplexing at first. It’s a definite mind shift.

Now you can create perma-links that are independent of the display template. The Pages and Structure modules achieve exactly that.

But all of this does make it harder to maintain the integrity of links, if people do commonplace things like change an entry’s url_title. There is no simple “update changed links” functionality—you’d have to delve into the Find and Replace utility, which is not at all user friendly.

—

As for the original poster’s comments about adding “arbitrary content” to a sidebar, this too is a philosophical approach common with a lot of mid-weight CMSes (RedDot, CommonSpot) as well as lots of open source competitors (Plone, Drupal, Typo3, et al). They allow for you to easily attach arbitrary sub-objects to the entry, making for a very modular “page” concept.

This can be done with EE (and done well) through multiple weblogs, and relationships. But even with advances like Playa, it’s not an elegant solution in terms of the content manager’s experience.

And for better or worse (mostly better), EE simply isn’t a CMS based around modules that get slapped into a right hand column.

—

Finally, I feel that the reliance on third party extensions for WYSIWYG editor integration is a weakness. We should have a first party WYSIWYG option with good integration into the content store for linking, inserting images, etc.

I’m sure some of us would never use it, but it’s a strange omission in this day and age, when WYSIWYG components are standards based, no longer relying on the Microsoft tax.

—

There are other things that often freak clients out: the middling support for arbitrary page heirarchies (thank the lord for Structure!), for previewing and workflow, for deployment between Staging and Live server instances… If it weren’t for people like Travis and Leevi, we couldn’t deliver a solution that competed with the stronger commercial solutions out there.

So I think we should continue to ask hard questions about how we can all make EE better. It’s absolutely my CMS of choice, but I’m not naive enough to think it’s perfect.

Che

sigork - 18 April 2009 02:10 AM

Cem Meric - 18 April 2009 02:04 AM

Care to share some details

http://expressionengine.com/forums/viewreply/441356/

Cem Meric - 18 April 2009 02:04 AM

solutions etc.

I described the problem to Leevi. No solution.

But it is not the only solution out there.

lebisol - 20 April 2009 09:17 AM

But it is not the only solution out there.

What exactly do you mean?

P.S. Every of these “coffee-making machines in the back room” has its own incompatibility w/ EE (for example). So, they are “quasi-solutions”. You can spend much time (trying all of these “machines”) and get a bad coffee.

If you are a web programmer and sell your final solutions, you can successfully use them (after fixing them) and sell one fixed extension many times (in websites). My congratulations.

If you are an end user and don’t have time to repair a “coffee-making machine” to drink one cup of coffee, it is better to use other system (which has, e.g., built-in wysiwyg, multi-membership (member in several groups), full paypal support/shop (ready out of box to sell membership & downloads) and many other ready-made features, etc.).

Product or “coffee-making machines in the back room”—the choice is yours.

sigork - 20 April 2009 11:32 AM

If you are an end user and don’t have time to repair a “coffee-making machine” to drink one cup of coffee, it is better to use other system (which has, e.g., built-in wysiwyg, multi-membership (member in several groups), full paypal support/shop (ready out of box to sell membership & downloads) and many other ready-made features, etc.).

What other CMS would you recommend to fill those requirements?

Meaning that LG ext is not the only way to get tiny editor into EE.
Are you complaining about the coffee or the machine? Because EE is the ‘coffee’ here while your designer should be the machine. Those kids in Starbucks have the best machines and yet always burn my coffee making it taste like crap.

All kidding on the side, if you are end user and a customer than that is different and you should talk to LG.

Sure EE has some shortcomings but…depends what you are after and what you needs are, I think that features are up front honestly listed.
All the best!

lebisol - 20 April 2009 12:03 PM

EE is the ‘coffee’ here while your designer should be the machine.

In your example EE is a semi-product. Websites made by designers will be cups of coffee.

So, maybe EE is an advanced framework for web developers? Not a CMS?

sigork - 20 April 2009 12:48 PM

So, maybe EE is an advanced framework for web developers? Not a CMS?

How about a definition for “CMS?”

Based on a generally accepted definition from Wikipedia, it would appear that EE is a CMS.

A content management system (CMS) is a computer application used to create, edit, manage, search and publish various kinds of digital media and electronic text.

CMSs are frequently used for storing, controlling, versioning, and publishing industry-specific documentation such as news articles, operators’ manuals, technical manuals, sales guides, and marketing brochures. The content managed may include computer files, image media, audio files, video files, electronic documents, and Web content. These concepts represent integrated and interdependent layers. There are various nomenclatures known in this area: Web Content Management, Digital Asset Management, Digital Records Management, Electronic Content Management and so on. The bottom line for these systems is managing content and publishing, with a workflow if required.

That works for me. We may call EE something else, maybe even use EE in surprisingly different ways, but if it looks like a duck, walks like a duck, talks like a duck…

sigork - 18 April 2009 02:10 AM

Cem Meric - 18 April 2009 02:04 AM

Care to share some details

http://expressionengine.com/forums/viewreply/441356/

Cem Meric - 18 April 2009 02:04 AM

solutions etc.

I described the problem to Leevi. No solution.

If you had the TinyMCE as a wysiwyg editor working before installing LG TinyMCE extension why did you even install the extension in the first place?

Plus, as Leevi Graham said

a SAEF form is exactly that… A stand alone entry form. It has nothing to do with the cp.

I think that Sigork just didn’t get the help he needed on this one… leading to confusion on a lot of fronts. What seems to have happened is that when he installed LG Tiny MCE, those fields no longer showed up in his SAEF although they were working just fine in the control panel.

There is a reason this happens, and it is kind of a conflict with EE I suppose. This happens because in a SAEF, the {custom_fields} loop is looking for a textarea to be set a certain way, but LG Tiny MCE makes you set it as a WYSIWYG field. The funky loop then goes, “I don’t know what that field type is.”, so I’ll ignore it. So, the fields don’t show up and LG Tiny MCE appears to break your SAEF whether you want the WYSIWYG editor in your form or not. Solution is simple, but cumbersome… don’t use the {custom_fields} loop and hardcode the form instead… not necessarily a happy solution if you have 30 custom fields. Of course, I didn’t mind because I wanted more control over the look of the form anyway, so I generally hardcode forms.

Anyway, LG Tiny MCE is an incomplete solution in this regard. This does not happen with TinyMCE, but Sigork had a different problem with that plugin, so I figure that’s why he tried LG Tiny MCE… if one solution doens’t work, try another. That solution didn’t work, he didn’t get good answers, and he got frustrated. Makes perfect sense to me.

I should edit what I just said… LG Tiny MCE may not be the “problem” in a sense. The {custom_fields} loop may really ultimately be the problem because it is completely inflexible. It is not only LG Tiny MCE fields that have this problem… I suspect any field where a specific field type is set would also have this problem. Even hardcoding the form sometimes doesn’t work with other field types and I’ve had to resort to php (which I’m not opposed to in small, easy quantities). Certain fields, like data matrixs, I haven’t even really tried.

Shannon Smith - 20 April 2009 05:13 PM

There is a reason this happens, and it is kind of a conflict with EE I suppose. This happens because in a SAEF, the {custom_fields} loop is looking for a textarea to be set a certain way, but LG Tiny MCE makes you set it as a WYSIWYG field. The funky loop then goes, “I don’t know what that field type is.”, so I’ll ignore it. So, the fields don’t show up and LG Tiny MCE appears to break your SAEF whether you want the WYSIWYG editor in your form or not. Solution is simple, but cumbersome…

I see what you mean Shannon but there is a reason why LG Tiny MCE is not taking over textareas entirely is to give you option to use both as necessary.

You can still use wysiwyg fields in somewhat easy way with a bit of sql

That’s a cool way of dealing with this, but doesn’t give you any control over the order of the fields. The loop will loop through in the order defined by you for your custom fields. If you can simulate the loop and add in the wysiwyg fields, that would be a better solution. What I mean is bypass the {custom_fields} loop entirely with your query code and somehow bring all the fields in with the proper order using your query code above. Is there a way to do that? I mean, wouldn’t you be able to just put in the code that normally goes in the loop within your query (with your cool addition of the wysiwyg field) and somehow order it properly that way? I love this idea… I just think breaking it up doesn’t make sense, as there may be a reason for ordering fields differently.

And I totally agree by the way… LG Tiny MCE should NOT take over textareas completely. A better solution would be flexibility build into the loop in the first place if at all possible. A new field type is added, maybe there should be an easy way to add that into that loop. Then, when everyone asks the developer if it works in a SAEF, it can fairly easily.

What I mentioned might get tricky, as you might have to treat the title, url-title, entry-date, etc. differently. I guess that all depends on what’s in exp_weblog_fields and maybe you can get around those fields with conditionals.

Maybe if we figure out a good solution, it can be wiki’d or something. There have been many people stuck by this. Maybe even include it in the documentation for LG Tiny MCE.

I think that is the complaint at times… there are solutions out there, but often hard to find. More documentation would help. I know people read the documentation for EE and the various addons… so, documenting things like this isn’t a waste of time.

Shannon Smith - 20 April 2009 09:41 PM

That’s a cool way of dealing with this, but doesn’t give you any control over the order of the fields. The loop will loop through in the order defined by you for your custom fields. If you can simulate the loop and add in the wysiwyg fields, that would be a better solution. What I mean is bypass the {custom_fields} loop entirely with your query code and somehow bring all the fields in with the proper order using your query code above. Is there a way to do that? I mean, wouldn’t you be able to just put in the code that normally goes in the loop within your query (with your cool addition of the wysiwyg field) and somehow order it properly that way? I love this idea… I just think breaking it up doesn’t make sense, as there may be a reason for ordering fields differently.

No need to break it up indeed, we can get all of them via exp:query tag while respecting field order settings.

Just need to do necessary checks e.g. textinput, date etc. depending on custom fields as you would in {custom_fields} loop.