(Who am I kidding, I can’t count to 10…)
These are not in any particular order, and I can almost guarantee there won’t be 10 things… that just sounded better than “Top Several Things”. These are just some of the “to-do’s” and “would-be-nice’s” that I’ve identified so far as I’ve mapped out my project plan for the next few months. Some of them are probably slam-dunks, and others are probably criminally insane. Any feedback (insight, encouragement, discouragement, whatever) would be greatly appreciated.
- Integrate “Manage Users” with our company LDAP information. So I can add users by selecting them from a list of all existing employees. Because I hate typing in employee information that already exists somewhere else on the network.
(I am fully aware that this will probably take longer for me to figure out than it would to just key in the employee info for the 2-3 dozen people who need accounts… and I’m still hell-bent on doing it). - Integrate Manager authentication into our intranet site. In my MODx dreamworld, my users will log in to the company intranet, and, if they are MODx users, will be simultaneously logged in to Manager, with some sort of smart link on the screen to make them aware and take them there. (I’m in various stages of doing the same thing with our web/calendar, our web file storage server, and our helpdesk call tracking system. It just seems like the thing to [attempt to] do).
- Identify the most logically sound template strategy I possibly can. By which I mean, gain a better understanding of when/how to best use Template Variables (among other things, some of which I’m probably not even aware of yet) to allow the use of one or two primary templates across our entire site. Our design scheme isn’t too complicated – I’m going to need to customize some background images, probably based on “department” and “parent department” affiliation of the pages. First I have to figure out the “business logic” (which parts of the design are fixed globally, which parts are fixed based on belonging to a department, and which parts can be overridden at a per-page level). Then I need to understand TVs & etc. well enough to transpose those rules into some sexy & ruthlessly efficient template logic.
- Rock some custom page-specific jQuery. This is the one I’m most excited about at the moment. Because jQuery makes life worth living, I want to be able to allow some (read: a carefully vetted elite group of users who WON’T BREAK THE INTERNET) of my MODx editors/page-wranglers to use it on their pages. I think I have a sound plan mapped out involving the use of TVs and chunks to create an à la carte library of handy pieces of jQuery. Hopefully I’ll flesh this out and do a full-length post on it someday soon.
- Implement a revisioning system, or at least a solid backup/recovery plan. This is CYA territory, plain and simple. In our current Dreamweaver/FTP-based publishing paradigm, when someone blows away or hopelessly bungles a file or directory, we at least have the option to restore it from tape backups. I don’t necessarily need something more finely-tuned than that, but I do need to offer at least the equivalent of that. I’ve been avoiding dealing with this issue, but it isn’t going away on its own.
…and with that, I’m out of gas for today. Too lazy to re-edit the title, I’ll just leave this as a list of five things. Perhaps with more to come.
Advertisement
Posted by Ryan Thrash on February 11, 2010 at 7:59 am
Needless to say, I love this blog. Please keep it up!
1. LDAP starting point: http://modxcms.com/forums/index.php/topic,44833.msg265026/topicseen.html#new
2. and 3. We should set up a chat sometime. We’ve got lots of experience here … shocking I know.
4. Registering your stuff in the page can actually be pretty easy. You could set up a series of checkbox TVs to trigger specific things on a per-page (Resource) basis, and it’ll work just like magic. In theory.
5. A mix of SVN and careful staging workflow can make things better. But when you get into DB-based CMS platforms, the stuff in the database gets tricky. Definitely adopt Subversion or other source code management and make your team use it!
I noticed you left off get involved more closely with the MODx community and development efforts. We’re always on the lookout for motivated developers who just get things done.
Posted by james on February 11, 2010 at 9:12 am
Wow thanks for the tips Ryan. I’d love to chat with you about #2&3 sometime soon, that would really help me along.
For #4 I have this (probably dumb) idea of basing per-page jQuery on the existence of a child resource named (something like) jquery.js. The template would have a global jquery block (for the jquery that relates to the site-wide/global aspects of the front-end design) with a snippet inside it that would look for the existence of a jquery.js child resource and if one is found, parse & include it. Any given jquery.js file could include straight jQuery and/or chunk tags referencing a central library of useful jQuery bits.
The advantage I see to this approach is that if I wanted the custom jQuery on page #755 to be exactly identical to the custom jQuery I used on page #521, I could simply reference the jquery.js child of #521 by its ID – rather than having to recreate the “recipe” line by line.
The reasons I suspect this might be a bad idea are #1) I suspect that perhaps relying on separate resources, rather than elements, might be a performance drag (?) … #2) I suspect this might be another example of my standard M.O. of becoming enamored with “my solution” in lieu of learning the system more thoroughly to identify the “best of breed” solution. Which is to say, I really don’t have a concept yet of the intrinsic value of TVs in order to identify a TV-based solution to this problem.
#5 I feel like I have a long way to go to even begin understanding the concepts.
And yes, getting involved more closely should definitely go on my list. Part of my motivation for starting this blog was to spread the word and find a comfortable way to network with the MODx community based on “where I’m at” right now… as opposed to spamming the forums with every little question I have. I’ve been flabbergasted at how responsive and helpful the community has been right from the start, and I look forward to increasing my involvement as much as possible.
Posted by ridgerunner on March 1, 2010 at 6:04 pm
For #5: Use Git. Not CVS. Not SVN. Git!
Its dead simple. To create your repository type:
>git init
To update your repository adding all recent changes type:
>git add .
>git commit -a -m “This is my commit message”
Then simply periodically backup the .git directory which contains the entire history of every version of all your files (i.e. “The Respository”). Its actually just a bit more complicated than this, but this is pretty much the gist of it.
Listen to Linus Torvalds talk about it here (this is what got me into it)
Then take a look at the excellent on-line documentation:
http://progit.org/ and http://gitcasts.com/
Note: I’d never even used source control software before a couple months ago (despite my having been programming for 30+ years – can you say “punch cards?” My old method was simply backing everything to zip files periodically) Git has changed everything for me – for the better. (and note that I am not a Linux/Unix person – this is coming from a Windows user!)
Great blog BTW – see you on the MODx forums (I’m brand new to MODx too)
Posted by Managing CSS and Javascript/JQuery in MODx templates and pages – Part One « The CMS less traveled on April 16, 2010 at 2:36 pm
[...] level. Long-time readers from back-in-the-day (by which I mean February) will recall that this was one of my high-priority issues for using MODx Revolution. While I don’t quite have it all sorted out yet, I think [...]
Posted by daniel winks on May 6, 2010 at 12:31 pm
Depending on what you are needing for #5, you might be able to just get a dropbox account and install the linux/windows/mac client (depending on your server) and make the dropbox folder your webroot.
$10/$20 a month gets you 50GB/100GB of storage, and each time a file changes, it saves the previous version. The paid versions of dropbox include unlimited versioning, file-rollback, undelete, etc. You could do all of that via their website, so you wouldn’t need to run any sort of GUI program on your web server.
I’ve used dropbox before to implement a cheap, fast and easy backup, versioning, and undelete system on a couple smaller servers, it worked pretty well.