So if I understand it right, it could very well be removed in the core for 2.0?
We'll need to see if a one-time treatment is needed on upgrade of an existing site.
Do linebreak goes back to having a dhtml editor and wysiwyg editors and does go back to XOOPS, when wysiwyg integration was being added through Frameworks.
I think some of the editors - FCKeditor if I recall - generate extra returns in their generated html.
This is to stop it ... I think.
As mentioned in the topic http://community.impresscms.org/modules/newbb/viewtopic.php?post_id=48002#forumpost48002 by @bleekk, our modules still offer several options that date back from the Xoops time.
* Enable Smiley Icons
* Enable ICMS codes
* Enable Linebreaks
The first 2 options look to me like config options for the editor in combination with page and user group.
The 'Enable Linebreaks' seems a bit outdated. Does anyone know what it does exactly, and if it still makes sense to keep it?
I generally agree with Will, but some ideas:
* Can we put together a 1.3 compatible/maintained module pack, and make it available either as part of the core system download (best) or include a link to it on the downloads page / get it now box so people can find it easily?
* Re. nice URLs, this should be fairly easy to implement, depending on "how nice" you wanted them. It could probably be done via a very simple module and index redirect, I will start a new thread on that one shortly.
* Re. integrating content, a single core publishing interface would be great and would certainly help with nice URLs and site wide tagging, although it might be a lot of work.
* Re. editors, this is another of my bugbears but if a common hook system is developed I'll try (no promises) to integrate a WYSIWYM editor that ties users down to a range of preset styles, rather than letting them rampage with a wild selection of font sizes and colours.
* Re. site redesign, I would be very happy to help with this, although I'm not sure how compatible my ideas are with everyone else (eg. roll sites into one). If I get involved I will want to change things wah ha haaaaa :)
Here are some points that I personally think should be changed/improved.
1. remove all icms/xoops related code/options from the comments and all other places where it shows up. Remove it from the core completely.
2. Remove banners and profile modules from the download package.
Instead of providing it in the donwload sell it big on the icms homepage. Make a big banner where you show profile module as an extra module that is great and that every one can donwload for free.
3. There is no webpage without content. So integrate the content module in icms. Why integrate? Because you can then make a better usability to the user. See 7.
4. Menu management. There is no cms without menu management. Take a menu module and intagrate it. This module has to provide clean html code. Please not too much extras.
Usability seems to be one of the key things in the 2.0 branch - so myself I'm certainly in favour of it being done.
If we want to pull this off, we will need more active developers that contribute to the core. This is a timing isue : either we wait another year for these things to be added/rewritten, either we do it incrementally in 2.0, 2.1, 2.2, ... but with a strict roadmap what will be included in what.
This also is with the assumption that no more work is done on 1.3.x, because that would dilute resources even more.
I think that ICMS 2 should be held off until we fix these problems. It is a major milestone release - and this is the best possible time to re-imagine and reinvest in the system.
If we let it go past 2.0 then we will get back into the same broken record we have been in for years (compatibility/upgrade/etc)
Now is the time, if we are going to invest this much effort in 2.0 - we should launch it with our best foot forward.
To make sure I understand : for example : If I want to show a block on the site, I need to go to several places in the admin section to set the visibility and the group permissions before the block will show.
What you mean here is that the page for the blocks should give access to all the necessary config options to control the block. I couldn't agree with you more. We need to have more separation between how the system is organised internally and what we show the user.
I wouldn't say that exactly - I don't think throwing an editor at it will fix what I am describing.
What I am saying is that you can not have such a disjointed experience for the user - there is no workflow. Make a workflow that is clean and easy to understand.
1. Fix the workflow
2. Add these long awaited features
There really is nothing to discuss other than who will do it? I can do the frontside - but that is only a tiny piece of this discussion.
I think I understand.
So basically - a standard "editor screen" which could be used front or admin end - which all modules use?
A unified administration means that modules should provide new or extend existing functionality - that all content entry should be done in a cohesive and unified manner from a centralized location - and that the interface for doing so should be rich yet simple.
A user should not have to run all over the administration to construct a single page.
The "modular" approach in ICMS is great - but it has created an extremely fragmented system that allows each individual module to control it's own content and content entry - that part is flawed.
Simple media management
Simple content management
For myself - the ideal plan would be the following:
Make a package of a couple of standard extra modules to go with the core, to cover most common usages. I'd suggest Menu and either CMS or Impression.
This would mean we'd provide: Protector (security), Profile, Banner, Content (still a useful module for single page content) - although ideally needing an update), a multi-page content module and Menu .. with one of our install options.
This could be offset by a module pack of other most-needed modules.
The modules that come with the core by default... we optomise the presentation to make them uniform in how they look and feel to new users. Make sure the icon style and presentation is easily recognisable for functions, make sure they all have easy to follow help, etc.
We later do the same for modules in the pack. The point being is to make it easier for people to use each module by instinct - instead of wondering "what does this icon do?" "What does this option do?" etc.
Improving the editor on the core side to remove the confusion is a part of this stage. It's not so simple to configure editor usage on each module - at least not for a newcomer. (How many people would think of looking in "groups" to control who can use which editor etc?)
Don't know how much sense this makes so far
nice suggestion about the symlinks, hadn't thought of that I'll put a change request on assembla to start with.
A small suggestion - but perhaps including the menu module (QMB's is rather good) with the core install could be a start?
The module is very good - although perhaps being able to select from existing Symlinks could be a nice addition.
i wouln't say these are considered low priority. There's just a finite amount of stuff that a small team can do. I've been thinking about most of these things, and it's incredible how much they are affecting each other.
* Clean URLs are easy to do for incoming connections, but we'll need to figure out how to handle (and transform) the links on the pages of the site. The links are not managed by the core at the moment, but we should, if we want to do any of the more interesting things.
* Media Management should take over control of all the assets that you use on your site : images, files, downloads, ... (maybe even URLs?)
* Menu management : that's easier to do, if you just want plain and simple menu builders. the 'menu' module is a good start.
* simple content management : that's a pet peeve of mine : we should structure the site the way we want it, not according to the different modules we happen to have. I've been discussing this with Steve, and we both think that the way to go will be making much more use of blocks in order to organise the content more flexibly. That way, the modules offer a kind of data, and you have a pagination module that lets you assemble pages based on different blocks. The User interface to get this working will be the make-or-break for this, it needs to be easy and flexible
* unified administration -> Not exactly sure what you mean by that. Administration should be more flexible and should be more logical (who needs 5 items to manage users, isn't the 'general' section way too big?)
And I still believe the 2 things I mention above are relevant as well : Ajaxify the core and make api integration easier.
I re-iterate what I say each time : don't let us stop you, jump right in Don't stop just at asking, but start talking to people on the forums about what you think a feature should do, find people to help you, start writing code, ask questions if you get stuck.
It's the only way to be certain that ImpressCMS evolves in the way and direction you want it to. If you let someone else do it, it will be done his way, and you won't have any reason to complain.
bleekk is right - we can't expect to get any kind of coverage if we refuse to offer basic functionality. If we want people to write about us, there can't be this nonchalant attitude about these critical features that are missing - and continue to be considered low-priority additions.
Simple media management
Simple content management
The problem is that ICMS is written for developers - and it is not too often that developers build websites that don't need to meet the approval of regular users.
I know when I am paid to build a site for a client - they want the administration to be stupid-simple - and ICMS does not even come close to how easy systems like this make it for regular joe-smo users to add content and manage the site.
I have used pyrocms for one project. maybe that icms offers the same functionalities like pyrocms but pyrocms makes it better.
much things are easier to use(file/image upload, editor, ...) and there are some things that icms still does not have (menu management, nice urls, easy switch between development-productive environment)
overall there is a much more modern look/feel and much much better usability.
sorry for this kind of criticism but it is time to wake up and rethink some things in icms