The reactor group (not branch) for CodeIgniter started in an effort to have a branch of CI that the community was responsible for maintaining and adding to with oversight from EL.
Recently the idea came up to harness this idea for EE. That is what is being discussed in this thread.
A lot of good writing here. As per i am more designer than dev - yet i still love to use EE even it dont have all the things i would love it to have.
I’m self learned(even tho EE2 is not yet under my skin so to speak) to use EE, well huge thanks to community that helped me in the first run, since i once bought it without any kind of base knowledge on how to use - make - create sites with it. I just found EE and rest is history.
What i try to say here - is that EE is maybe targetted for real web profs but do not forget that there is lot of people like me out there - maybe we arent the best customers but surely we are people that love to work with EE to make sites for ourselfs and clients.
Bugs and lack of features are never ending story and i, personally just live with what i have now in EE and hope that someday someone pops up and sells module or EL makes those missing features into core.
I hope that things dont go the wrong way with EE cos i just dont want to use any other platform
PS. when EL makes forum easier to skin
Seriously - i hope that support stays as it was when i really needed it (well atm i really need it too and hope that we get the DB problem solved soon or i run out of time).
The Drupal story has been interesting to follow. There are some valuable lessons to learn from it, mostly what not to do and generally, the pitfalls of Open Source for a large scale CMS/platform.
Drupal is also suffering from growing pains; lack of appropriate direction, spiralling bloat and complexity, releases with unfinished features, a heated framework vs product debate, disagreement over which contributions get into core. D7 is a bit of a mess in many respects and it looks like it experienced a ‘kennygate’ recently, one of many I suspect.
Any org blindly specifying Open Source might want to dig a bit deeper and understand the implications; right now they don’t, but this could change.
On the other side of the argument, there is much to learn from Apple’s astonishing success with iOS+apps; a very tightly curated ecosystem which has been derided for being a walled garden but actually fosters huge developer activity and results in high quality, a consistent UX and a wide choice of apps. There are parallels between the EE and iOS+app store concepts - what can we learn from this? Does EL now need to manage the ecosystem more closely and move beyond simply providing hooks and ‘helping’ Devot:ee?
The real, honest to god knocks against EE itself are also a concern. They are:
1. The installer.
2. The CP.
3. Support.
4. Stability (aka bugs).
CP needs a serious overhaul. It has poor usability, it is slow and unflexible. It is sad to say, but CP of EE1.x was much better.
Perhaps the worst thing in EE2 CP is removal of all hooks allowing to add columns to Edit Entries list table. I mean edit_entries_additional_celldata, edit_entries_additional_tableheader hooks. There were other hooks allowing modify edit entries list which also gone: edit_entries_decode_date, edit_entries_extra_actions, edit_entries_modify_tableheader, edit_entries_modify_tablerow, edit_entries_search_fields, edit_entries_search_form, edit_entries_search_tables, edit_entries_search_where. Using those hooks it was possible to add additional selectboxes in the edit entries search form. There were in EE1 popular add-ons as Filter By Author http://devot-ee.com/add-ons/filter-by-author and Filter By Sticky http://devot-ee.com/add-ons/wi-filter-by-sticky I pub.lished extension Filter By Comments http://devot-ee.com/add-ons/filter-by-comments and Filter By Edit Date http://devot-ee.com/add-ons/filter-by-edit-date Now a.ll those add-ons are unportable to EE2 because of the lack of hooks. Instead of flexibility we now have on Edit Entries list page unneeded ajaxy whiz-bang which probably complicated the code very much and hinders reintroduction of hooks. Developers are very interested in those hooks as it could be seen in this thread http://expressionengine.com/forums/viewthread/185398/
It seems strange to me that the requests of the developers to return hooks or to introduce new ones are steadily ignored. Most of such requests are very easy to implement: the hook consists just in couple lines of code.
I see I’m months too late to this discussion. Firstly, I don’t have much by way of negatives to say about EE or the team behind it. I also find working with the top 3rd party guys an absolute pleasure.
One thing I do agree with however, is that the growth of good 3rd party commercial add-ons has definitely restricted development and growth of the core platform. Sure, we can pay for them and add them in, but because they exist, and because they’re built by developers who EE subsequently develop relationships with, they will almost never make it into the core product (with the exception of Safecracker), and this is could be crippling down the line.
To my mind, certain add-ons should be commissioned or purchased and included into EE where they are clearly going to significantly improve the platform. Things like User, Super Search, Playa, Wygwam, etc being obvious examples. This is an investment that to my mind would significantly speed adoption of the platform.
The problem with them is not only the cost of each additional component but the fact that the development of those components are not guaranteed to keep pace with EE updates. Even in the case of a fantastic add-on like super search, which recently had to be modified after an EE update was released. Not knowing how fast fixes will be provided is a risk when deciding on what you can implement.
I’ve always hoped EE would work towards more of a commercial relationship with the top devs, and align their interests to bring the best of the best into the platform.
Having come this far down the road, with companies like Solspace being built on the back of providing these commercial modules, it’s a tricky model to change now. The problem with not wanting to step on toes is that it blocks a lot of obvious paths would likely have been followed.
How good would it be if directors of Solspace, P&T etc could be given some skin in the game to get on board and build everything into the core.
I have no problem with the license fee either. I’d happily pay an extra $100/$200 on every license to have my top 10/15 commercial add-ons included in the core install.
I’d happily pay an extra $100/$200 on every license to have my top 10/15 commercial add-ons included in the core install.
The thing is, everyone has different ideas about what is essential. I’ve used nearly all the addons you mentioned in different situations, but I certainly don’t use them on every site, and not sure I’d want all that rolled in to the base product.
You wouldn’t want them included? You could simply switch off any component you didn’t want in a particular installation. I fail to understand this logic, and I don’t think you’re appreciating that I’m saying good commercial modules are essentially stopping the platform’s own development in various areas.
The comparison between EE’s native search and Super Search is world’s apart, yet because a relationship exists with Solspace (yes, I’m assuming but it’s probably a pretty fair assumption), who have a business built around selling their modules, I can’t remember when the last improvement or significant change was made to EE’s search.
EE’s lack of a decent native WYSIWYG is diabolical. This should have been added years ago.
There are any number of examples of really clever re-engineering that has come from the dev community (Blueprints, Playa, Super Globals, etc), and almost none of them have altered the core product. Other things like the lack of connection between a mailing list and a member makes no sense and could be improved yet no change to any of that. To me, this is a somewhat lazy approach to building the platform (which I still love even though I’m having a moan).
Sure you can still run a successful business this way, but you aren’t going to blow the world apart with a market dominator. If you want proper innovation and fast growth you invest in it, whether by raising capital, sharing some equity, or hiring talent. While Apple has a commercial marketplace for its apps, it’s also out there acquiring talent, developing it’s platform and innovating rapidly.
EE has a real shot at being a leader, but not by letting the platform stagnate and expecting the community to provide the innovation in the form of commercial additions.
On a side note I thought this was interesting about what Presidential candidates are using as their CMS. I think each site could have easily selected EE as their platform. Sure would have been nice for EE and all of the EE developers out there. http://wpjourno.com/2011/08/17/presidential-candidates-wordpress-cms/
Not sure if this is a blessing or a curse, but I’m pretty sure Herman Cain is actually using EE:
I have to say I agree with Calan. There are commercial addons that should absolutely be a part of the core.
Perfect example: I just paid $20 for the ability to list child categories of a given parent (http://devot-ee.com/add-ons/child-categories). I mean, come on. It’s absurd you can’t do this natively.
I’m not saying every addon should be a part of the core, but let’s look at some other examples of those that should:
1) WYGWAM (or any decent WYSIWYG solution).
2) Custom System Messages - EE allows you to edit the template for showing error messages to the end user, but it’s only editable from within the CP, and you can’t embed other templates. So if you have a header and footer template for your site, you’ll have to copy/paste that code and make sure you maintain both copies if you ever change it. This is a massive oversight.
3) Zenbu - EE is quick to point out that it assumes nothing about the nature of your content. You would think that this means EE also assumes that Title/Author/Date/Status aren’t always going to be enough fields to search and navigate your content in the Control Panel.
4) Edit Alarm - Is it so much to ask that when editing a channel entry we be notified when someone else is already editing it? Just a simple “Hey, FYI, John S. is already editing this entry.” For a true multi-user CMS, this is a *requirement*
5) Assets - find me a single person that prefer EE’s native file management to this.
...and more…
Anyway, I’m getting a bit off topic here, and I realize some of these may already be feature requests in development. If so, great. My larger point is that you should understand why it is frustrating that these basic things are not included in the core, and furthermore, why it’s frustrating to get “there’s a commercial plugin for that” as a response when asking about it in the forums.
Don’t get me wrong, I do love EE for a lot reasons, and so far those things have outweighed my frustrations. But what I’m realizing more and more is that the stuff I really love is the stuff that I paid a 3rd party developer for—a developer that seemingly understands what EE’s potential is more than Ellis Lab.
I just really really really hope they don’t start including 3rd party anything in the core, and just focus on developing the product. if the back end weren’t so clunky I’d be happy, but the last thing I want is to spread the dev team any thinner than it likely already is.
if you don’t understand how bad adding 3rd party options are, just go read up on Drupal and the state of it’s development. it’s bloated now, which is a very good reason not to want it.
everyone wants their top ten included. not add those people together and it becomes the top 1000. it’s not difficult to go to devotee to get your add-ons, and it’s much better to only pay for what I use.
I too hope the core doesn’t get bloated with 3rd party addons - developing the core is far more important.
There are some functionality items that should be addressed in the core, eg the ability to list just child categories which currently needs a plugin.
For things like WYSIWYG’s I’d far sooner have a choice of which one to add, we have several 3rd party WYSIWYG’s to choose from, each one fits a certain type of need so even if there was a default one included it wouldn’t be right for all projects. Of courses not every site uses a WYSIWYG so if it’s included in the core it’s bloat!
I too hope the core doesn’t get bloated with 3rd party addons - developing the core is far more important.
There are some functionality items that should be addressed in the core, eg the ability to list just child categories which currently needs a plugin.
For things like WYSIWYG’s I’d far sooner have a choice of which one to add, we have several 3rd party WYSIWYG’s to choose from, each one fits a certain type of need so even if there was a default one included it wouldn’t be right for all projects. Of courses not every site uses a WYSIWYG so if it’s included in the core it’s bloat!
What is a CMS for? It’s a CONTENT MANAGEMENT SYSTEM. Who is it for? The client with no technical skills. What does he need to do? Manage content including images and basic text formatting. WYSIWIG including placing and auto - resizing images is a basic core function of a CMS. Not a addon. Just for this reason I cannot sell EE to clients anymore. (Wygwam is bloated slow and confusing for clients) Wordpress sets the standard here. A nice WYSIWIG made for the USER. Insert image left or right and auto lightbox to the full image.
Is this too much to ask for? And for developers who think this is not needed add a checkbox to remove the steering wheel from the car.
For those mentioning a wysiwyg - EllisLab has mentioned that they intend to ship a feature that meets that need at a new level. From what I recall it won’t be as feature-packed as CKEditor (used by Wygwam) but will supply users with more tools than come out of the box today.
mint - 29 December 2011 02:02 PM
Just for this reason I cannot sell EE to clients anymore. (Wygwam is bloated slow and confusing for clients)
I’ve never had an issue selling EE to a client. I’ve also never had Wygwam confuse a client after a small training session.
I too hope the core doesn’t get bloated with 3rd party addons - developing the core is far more important.
There are some functionality items that should be addressed in the core, eg the ability to list just child categories which currently needs a plugin.
For things like WYSIWYG’s I’d far sooner have a choice of which one to add, we have several 3rd party WYSIWYG’s to choose from, each one fits a certain type of need so even if there was a default one included it wouldn’t be right for all projects. Of courses not every site uses a WYSIWYG so if it’s included in the core it’s bloat!
What is a CMS for? It’s a CONTENT MANAGEMENT SYSTEM. Who is it for? The client with no technical skills. What does he need to do? Manage content including images and basic text formatting. WYSIWIG including placing and auto - resizing images is a basic core function of a CMS. Not a addon. Just for this reason I cannot sell EE to clients anymore. (Wygwam is bloated slow and confusing for clients) Wordpress sets the standard here. A nice WYSIWIG made for the USER. Insert image left or right and auto lightbox to the full image.
Is this too much to ask for? And for developers who think this is not needed add a checkbox to remove the steering wheel from the car.
I think you’re confusing a content management system (what EE has evolved to) to a publishing system (what wordpress is).
I’ve yet to have a business client that demanded a WYSIWYG, but I’ve added it to smaller sites that use it as a blog. then they want it for multiple non-technical posting. But most places I’ve worked with don’t use this system as a blog.
For those mentioning a wysiwyg - EllisLab has mentioned that they intend to ship a feature that meets that need at a new level. From what I recall it won’t be as feature-packed as CKEditor (used by Wygwam) but will supply users with more tools than come out of the box today.
It is my opinion that EllisLab needs to grow up and face the music. Sometimes it’s necessary to put a third-party addon out of business by adding features to the base ExpressionEngine product which make the addon superfluous. It would be grand, for example, if EllisLab were to implement a base multilanguage feature which far excels what’s out on the market. And why Playa hasn’t been made redundant by a really robust many-to-many relationship feature is also beyond me.
