Jump to content

List of other CMS's features


Nico Knoll
 Share

Recommended Posts

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.)

  • Like 3
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :-)

  • Like 3
Link to comment
Share on other sites

not sure I make sense :-)

I feel like that all the time..  :rolleyes:

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.

  • Like 2
Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

@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 :D

  • Like 1
Link to comment
Share on other sites

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

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 :D

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

  • Like 1
Link to comment
Share on other sites

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]);
  • Like 1
Link to comment
Share on other sites

@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?

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...