List of other CMS's features

[Nico Knoll]

Hey,

I guess we all used another CMS before switching to ProcessWire. And I guess everyone probably liked some bigger or smaller features of their old CMS. 

To close this gap or to replace this loss as good as possible it would be nice to collect a list of this features here. Probably there are things that can't be realized with ProcessWire the way you liked it in your other CMS. But always remember: Impossible is Nothing. #processwire

My personal list is/was:

Textpattern: 

- how to install a language (but I fixed that today https://processwire.com/talk/topic/6154-changes-in-how-to-add-a-language/#entry60210)

WordPress:

- it has a app (Tumblr got one, too)

- preview function

- switch themes (and the new browsing themes stuff: http://premium.wpmudev.org/blog/wp-content/uploads/2014/01/wordpress-themes-experience.png) (and live preview of themes)

- theme / admin settings (page title, subtitle) in a special place

- shortlinks

- automatic updates

Ghost:

- splitscreen markdown editor

Tumblr:

- Video/Media player

---

What are your favorite features?

/ Nico

[Pete]

Can I ask about the app for a sec - what's the benefit over a fully functional mobile admin theme? The API makes an app easier to accomplish than in many other systems but unless there's a clear advantage I'm not sure I see the point to be honest.

[Manfred62]

something like Media Sources in MODX would be a nice feature.

[Philipp]

The really nice modified TinyMCE in Wordpress. It looks awesome and feels much more developed than the PW defaults one. I also like the simple editor medium.com features, especially with the content "modules" you can insert.

No need for an app in my opinion.

[Nico Knoll]

No probably you don't need an app. It was just  thing I liked about Tumblr and Processwire

[onjegolders]

The ExpressionEngine module that made it trivially easy to show different looking Admin areas for different admin roles. Can't remember the name.

[diogo]

André, with the new module themes it's already easy to do it but for users and not roles (would be nice to be able to define it by role, though).

[yellowled]

Can I ask about the app for a sec - what's the benefit over a fully functional mobile admin theme?

I think that's a little different with WP (or almost any other blog system) compared to PW.

Some people may know that I'm involved in the development of the blog system Serendipity. One of the goals for the upcoming version 2.0 there is a new admin backend, which is also supposed to be responsive. Because given the fact that Serendipity only has very few developers, chances are more than slim that anyone will ever make an app, albeit one for iOS, Android and Windows Phone. So I've spent the past couple of months redesigning the “frontend of the backend” there.

Man, designing a backend is hard. I have sworn multiple times that I will never ever do that again. It is especially hard because there's lots of features to think about anyway as well as plugins adding functionality to the backend etc. Add the responsive stuff on top of that and you've got a shitload of work on your hands.

An app can make this easier. Designing a responsive admin theme means you have to account for any backend feature in all resolutions. With a seperate app, it's … “quite okay”, I guess, to leave out stuff which doesn't make sense on mobile devices anyway and focus on the stuff that people are in fact going to want to do with their blog system on a mobile device.

The beauty of the PW backend is that it's very … hm, “simple” sounds wrong. It very … streamlined, I guess. My point is, I think it is much easier to “get away” with a responsive backend theme in PW that in e.g. WP, just because of the overall structure and organization of the backend. (I hope that makes sense.)

[onjegolders]

André, with the new module themes it's already easy to do it but for users and not roles (would be nice to be able to define it by role, though).

Tell me more

[Pete]

The beauty of the PW backend is that it's very … hm, “simple” sounds wrong. It very … streamlined, I guess. My point is, I think it is much easier to “get away” with a responsive backend theme in PW that in e.g. WP, just because of the overall structure and organization of the backend. (I hope that makes sense.)

I guess another way to put that is "modules in PW follow some sort of convention in the way they are presented rather than modules in other systems where you can't predict how a module author might display the data in the admin"

Tell me more

Well in 2.4 admin themes are modules, so it wouldn't be massively difficult to override the user's choice and show a different theme (though not sure why you would). During install using 2.4 you get to choose the theme and the next step after that shows the installer using the new theme so there's probably some code there.

Alternatively if you just wanted to hide some things there are numerous ways including editing the default.php template file in the admin theme and showing certain things to certain roles (though there are better ways than that depending on your needs).

[onjegolders]

I guess another way to put that is "modules in PW follow some sort of convention in the way they are presented rather than modules in other systems where you can't predict how a module author might display the data in the admin"

Well in 2.4 admin themes are modules, so it wouldn't be massively difficult to override the user's choice and show a different theme (though not sure why you would). During install using 2.4 you get to choose the theme and the next step after that shows the installer using the new theme so there's probably some code there.

Alternatively if you just wanted to hide some things there are numerous ways including editing the default.php template file in the admin theme and showing certain things to certain roles (though there are better ways than that depending on your needs).

Thanks Pete, I guess what I mean is there was a way of doing this trivially in EE, which I think is in keeping with Nico's original post. To confirm, it's not to do with the "theme" but to do with what is being shown to different users/roles.

Here it is: http://devot-ee.com/add-ons/zoo-flexible-admin

I would also add in the way Meteor JS has very simple modules for adding in login functionality for users : password, Facebook, GitHub etc but I'm guessing this is just something we need more modules for (I think there are already some)

[dazzyweb]

The really nice modified TinyMCE in Wordpress. It looks awesome and feels much more developed than the PW defaults one.

I agree. This is definitely something that can be improved. Wordpress has also made further improvements to TinyMCE in latest wordpress 3.9.

[Nico Knoll]

I agree. This is definitely something that can be improved. Wordpress has also made further improvements to TinyMCE in latest wordpress 3.9.

Yeah, I saw it yesterday. They upgraded to 4.0.2.

---

Another thing: It would be nice if you could change the language (in backend) for all of the roles in one click.

[kongondo]

Well in 2.4 admin themes are modules, so it wouldn't be massively difficult to override the user's choice and show a different theme (though not sure why you would). During install using 2.4 you get to choose the theme and the next step after that shows the installer using the new theme so there's probably some code there.

Alternatively if you just wanted to hide some things there are numerous ways including editing the default.php template file in the admin theme and showing certain things to certain roles (though there are better ways than that depending on your needs).

Thanks Pete, I guess what I mean is there was a way of doing this trivially in EE, which I think is in keeping with Nico's original post. To confirm, it's not to do with the "theme" but to do with what is being shown to different users/roles.

Here it is: http://devot-ee.com/add-ons/zoo-flexible-admin

I think a discussion such as this one (I don't mean this topic but this posts) requires its own thread. Like Pete said, If this is an issue of what you want to hide and/or show in the Admin, PW, in various places and available API, already has various ways of limiting views. For example, the other day, Wanze showed us how the page tree can be hidden from view depending on 'role'. So, if we want this simplified in some module probably, we already have all the necessary tools. The main work (I say this naively) would be to unify these in some module. If we are interested in this, let's start a new thread and provide a list of the things we would like such a module to do in the one unified interface. I am writing this quickly - not sure I make sense

[teppo]

not sure I make sense

I feel like that all the time.. 

Seriously speaking, what I've been missing most is automated checking, logging and reporting for broken links.

This is partially solved by Page Link Abstractor, but I don't really like it's approach that much.. and it only works for local links. Manually running something like the W3C link checker helps a bit, but doesn't really solve the issue yet.

Another thing I'd love to see is proper Active Directory / LDAP integration. At least around here that's pretty much a requirement in order to build intranets etc. for larger organisations, as they all seem to use AD for managing their local users.

I know that there's some code floating around for this and Antti has apparently already used it in at least one project, but last time I checked it didn't really look like a finished product -- more like something that could probably be used to build on.

That's all I can think of right now.

[onjegolders]

I think a discussion such as this one (I don't mean this topic but this posts) requires its own thread. Like Pete said, If this is an issue of what you want to hide and/or show in the Admin, PW, in various places and available API, already has various ways of limiting views. For example, the other day, Wanze showed us how the page tree can be hidden from view depending on 'role'. So, if we want this simplified in some module probably, we already have all the necessary tools. The main work (I say this naively) would be to unify these in some module. If we are interested in this, let's start a new thread and provide a list of the things we would like such a module to do in the one unified interface. I am writing this quickly - not sure I make sense

The voice of reason as ever Kongondo

[Pete]

@teppo - I've got a marginally modified version of the AD module working, but to be honest AD is a pig to work with unless you know it inside out. I know it just well enough to get it to authenticate and that's about it - taking it further than that is hard work as it's hard to work with.

Something like ADLDAP would be the way to take it further I think: http://adldap.sourceforge.net/wiki/doku.php?id=documentation_user_functions

But even then, look at the docs - there doesn't seem to be something as sensible as a unique user ID in Active Directory so if you rely on the username from AD and someone changes the username on the AD server then your matching PW user account won't work.

Of course if you only need it for a bit of frontend authentication then it's not a problem, but if you want to match up an AD user with a PW user like I do on an intranet system I use then you have to be vigilant when changing usernames in AD.

I think I've thrown myself into a recursive loop and repeated myself a bit there, but that's the kind of headache it gives you

It would be great if there was a really good PHP API for AD that dealt with basic things like user authentication and reading/writing to user accounts (the basics in my opinion) but every one I've looked at gives me a headache.

But then I am spoiled by PW's API

[kongondo]

 ...But then I am spoiled by PW's API

Tell me about it! I don't know what's happened to me but the last few days I have found CSS more difficult than even PHP! OK, I exaggerate, but maybe I am becoming more comfortable with PHP. Maybe PHP is more predictable and 'relatively easier' to debug. Maybe my CSS skills are just lousy. No matter, CSS has been driving me nuts the last few days....currently it tops my list of least favourite 'web languages' (if we can call it that)! I know it produces the beautiful web....but beauty comes at a cost

<!-- Sorry to hijack your thread Nico.... -->

[Craig]

Of course if you only need it for a bit of frontend authentication then it's not a problem, but if you want to match up an AD user with a PW user like I do on an intranet system I use then you have to be vigilant when changing usernames in AD.

Hi Pete... I did something similar a while ago to sync active directory users with a mail server, using adLDAP. The unique ID was derived from the objectguid. Like this:

// Define the fields we want to get
$fields = array('sn', 'givenname', 'objectguid', 'description', 'displayname', 'useraccountcontrol', 'lastlogon', 'profilepath');

// Retrieve user info from AD
$userinfo = $adldap->user_info($username, $fields);

$id = bin2hex($userinfo[0]['objectguid'][0]);

[teppo]

@teppo - I've got a marginally modified version of the AD module working, but to be honest AD is a pig to work with unless you know it inside out. I know it just well enough to get it to authenticate and that's about it - taking it further than that is hard work as it's hard to work with.

Same story here; I know just enough work with it. Never written any code that would've connected with AD either, mostly just used an in-house integration and query tool

We've got a bunch of clients that use AD actively and based on that experience I'd say that a "proper" integration module wouldn't really have to do that much. Authentication, creating local users for AD ones (depends a bit on the use case whether that's actually desired, though) and finally a flexible way to connect users with roles (and possibly even custom entities, such as groups, if something like UserGroups is in use) based on OU's and/or groups would make it very useful already.

But even then, look at the docs - there doesn't seem to be something as sensible as a unique user ID in Active Directory so if you rely on the username from AD and someone changes the username on the AD server then your matching PW user account won't work.

Of course if you only need it for a bit of frontend authentication then it's not a problem, but if you want to match up an AD user with a PW user like I do on an intranet system I use then you have to be vigilant when changing usernames in AD.

Based on my (admittedly rather limited) experience usernames very rarely change -- can't remember a single case where this would've happened and caused problems -- and even if they do, it should always be possible to re-create (or rename) an old user account. I guess a changed username could cause quite a few other side-effects too, which might explain why admins seem to be rather reluctant to change these

On the other hand, according to this SO thread and some MS resources, there are actually multiple unique identifiers for users, so perhaps one of those could be used instead if usernames seem too risky?

[Pete]

People get married - that's the only time they would change aside from typos (both of which I've had to deal with).

[totoff]

When it comes to editors, my favorite is Redactor (http://imperavi.com/redactor/) which I became to know as part of Pulse CMS. If there is something I miss, it is a sleaker editor than TinyMCE is.

[Pete]

The issue with redactor is covered on this page here: https://processwire.com/talk/topic/1964-redactor-wysiwyg-editor/page-3

[dazzyweb]

The issue with redactor is covered on this page here: https://processwire.com/talk/topic/1964-redactor-wysiwyg-editor/page-3

That post was a while ago now. Maybe things has changed a bit.

Just scanned the licence quickly and there seems to be a slight change if i am correct

Before as shown in the old post: The OEM License is limited to one year from the date of purchase.

Now on Redactor Licence: Support for the holders of the OEM License is limited to one year from the date of purchase.

The OEM License: Holders of the OEM License may use the Software as if they had the Professional license. In addition, OEM License holders are allowed to sell or otherwise distribute the Software to the developers and not only to the end users. The OEM license allows license holder’s clients to develop their own products based on or containing Software. The OEM License holder’s clients do not have to obtain their own Professional or OEM license. The OEM License holders are allowed to integrate the Software with open source products. However, neither license holder nor license holder’s clients can sell Redactor as a sole product (with or without modification); License holder and license holder’s clients should use it fairly; Imperavi LLC still holds all the copyrights for Software code, Software code does not become open source, and we solely determine "fair use" of the Software. Support for the holders of the OEM License is limited to one year from the date of purchase.

[renobird]

We use Shibboleth for authentication here. The University handles how that integrates with AD, but once authenticated the environment variables give me access to a ton of attributes. I wrote a shibboleth login module for ProcessWire that we've been using for a few years now (a few months after I started using ProcessWire).

In my case the username is actually a unique ID set by the university. I'm not entirely sure if/how that is integrated with AD behind the scenes, but it never changes, even if you move from student to faculty/staff. Users actual names and other personal details can change, and they are automatically updated with every login. It also allows me to test for membership in and OU/Group and assign roles/permissions. So when a user is added/removed from a group in AD their PW settings are updated too. This happens at every login, and also twice a day via cron.

I've thought about turning this into a configurable module, but haven't stumbled into any spare time lately.

Lots of Universities in the U.S. use Shibboleth, so a module would go a long way towards ProcessWire adoption — especially considering all the other major players have Shibboleth modules/plugins.