Things I'd like moved to Modules/Plugins

Quote from: rthrash at Nov 09, 2005, 07:59 AM

Also need to look at updating or moving the phpmailer class to a plugin while we’re at it...

A plugin? Why would you want to do that? It’s an include file.

Because it could be replaced with alternate mail handling systems as needed.

Quote from: rthrash at Nov 09, 2005, 08:20 AM

Because it could be replaced with alternate mail handling systems as needed.

well I guess we could just create $modx->mail(). It looks like php mail() but it’s much more powerful. and can be made to support file attachments

example:

$modx->mail($to,$from,$subject,$body,$option);

Where options can be

$[’mail_type’] = ’smtp’;
$[’mail_format’] = ’html’;
$[’file_attachments’][] = array("myfilename.zip",$file);

Anyone want to give this function a go?

I’ve got a PEAR based htmlMimeMail.php class here that I’ve been working with and would like to turn it into something for MODx; it does all the things you’ve described here. What do you think? A plugin or API extension like the DBAPI? Shouldn’t take long once I decide on the approach to placing it in the architecture.

Ok...my own thoughts on a few of the items in that list:

Address book/contact manager (username/password remain the only "core" part) - onUserDetails
Most definitely needed! However, one approach would be to have this running as a module. Plus, I think the functionality should allow you to add your own fields within different categories that would show up as tabs. The default fields (username, password, etc) would be under a "User Information" category which would have a label/ID of default. Other tabs could be created with different labels/ID’s and display names that other custom fields could be assigned to. I’ve seen this sort of thing on a Mambo module...but it was a bitch to hack and manage and didn’t sync well with the rest of the CMS.

Statistics - onLogStat, onPageHit, or...
A couple of different modules for this would be a great help: One using a more optimized version of how stats work originally and perhaps one using a third party app. Removing Statistics and making it optional is definitely one thing that will help optimize MODx immensely for really large sites.

File manager/resource browser - onAssetUpload, onAssetPreview, on AssetBlahBlah
I think I mentioned this one once before. Definitely something that needs to happen! As it is, the resource browser is sort of a stand-alone thing anyways. However, the tricky-ass part is figuring out how to implement it as a plugin to where all the RTE’s will still have access to it via a custom plugin or configuration file.

Captcha/Human Verification - onHumanVerify
I recently played with a simple captcha script that is extremely easy to implement. If we implement the onHumanVerify event, this should allow us to use our own captcha plugins for things like a Guestbook on the front-end for blog posts...even if you allow for comments without the need for registering an account.

Syntax coloring/line numbering - onPluginView, onPluginEdit
I’ve played with Helene a little bit. Definitely need something to circumvent the textarea for editing plugins, snippets and such to make it work. Otherwise, two textboxes show up...the default one at the top and the Helene box at the bottom...not exactly the most efficient approach to code highlighting!

Authentication method (DB check, LDAP, Flat File check, etc.) - as exists
All I can say is: God we need this!! If we REALLY want an upperhand on some of the other CMS’ out there, the need for flexible authentication methods is a must! Right now, I have a need for authentication based on the LOGON_USER and REMOTE_USER server variables (using an LDAP module on Apache). LDAP authentication for both Unix/Linux LDAP server and Microsoft Active Directory will also be needed and is probably one of the most requested things with all the most popular CMS’. I experimented with it on Mambo and...well...although it worked, it caused alot of other modules that rely on authentication to not work properly. So...having methods that allow for more transparent authentication across the board is definitely a must.

Well...that should give ya’ll some major food for thought.

L8R!

Quote from: Bravado at Nov 09, 2005, 01:08 PM

Address book/contact manager (username/password remain the only "core" part) - onUserDetails
Most definitely needed! However, one approach would be to have this running as a module. Plus, I think the functionality should allow you to add your own fields within different categories that would show up as tabs. The default fields (username, password, etc) would be under a "User Information" category which would have a label/ID of default. Other tabs could be created with different labels/ID’s and display names that other custom fields could be assigned to. I’ve seen this sort of thing on a Mambo module...but it was a bitch to hack and manage and didn’t sync well with the rest of the CMS.

Authentication method (DB check, LDAP, Flat File check, etc.) - as exists
All I can say is: God we need this!! If we REALLY want an upperhand on some of the other CMS’ out there, the need for flexible authentication methods is a must! Right now, I have a need for authentication based on the LOGON_USER and REMOTE_USER server variables (using an LDAP module on Apache). LDAP authentication for both Unix/Linux LDAP server and Microsoft Active Directory will also be needed and is probably one of the most requested things with all the most popular CMS’. I experimented with it on Mambo and...well...although it worked, it caused alot of other modules that rely on authentication to not work properly. So...having methods that allow for more transparent authentication across the board is definitely a must.

I’ve had a lot of experience joining and integrating user repositories from various sources. There was a J2EE open source project called OpenSymphony that had a concept of pluggable, chainable user profile and authentication; osUser was a federated user system if you will, in which users with simple authentication needs would just configure their default authentication and user profile plugins and go, while power users and developers could chain together values from an LDAP repository, with more from Active Directory, and even more from an old custom user-profile database, using multiple plugins and defining priority for those plugins to execute. It even worked on multiple platforms by allowing additional plugins to handle the back-end functionality in whatever way made sense for the application server it was being deployed on. Long story short, it was the ultimate design I’ve seen for flexible user authentication and profiling. Imagine integrating LDAP authentication, with a large user base from SMF or PHPBB, with another base of users from Flyspray, along with our existing MODx user management system, and then possibly even offering single-sign on capabilities using the Security Assertion Markup Language (SAML), an XML standard for web authentication. And giving developers the option of writing their own plugins for it... I think this is what we will be able to do and demonstrate in the very near future with MODx, with just a few lines of code in a set of plugins.

Now that would absolutely kill Jason. Can’t wait to see it working after you finish it this weekend!

Sparklines are a cool way to get a quick view of data in a tiny amount of space. Could be cool for little access reports on pages in the manager, for instance:

http://sparkline.org/

FYI, Jonathan Snook from gaincms.com was going to do this in his manager.