On the former point I can say I was not disappointed. The venue was good and everyone involved was great. It was nice to put a face on many of the community members that I have been communicating with over recent years. I can honestly say that I had no appreciation for how long and how hard everyone at Collabpad has been working on the MODx project. All in all it was a positive experience.

On the latter point, coupled with an updated perspective on Revolution, my response was a little mixed. I would characterize the conference as being “programmer-centric”. The impression I also walked away with was that Revolution, at least in the short-term, is also “programmer-centric”. I have stated on many occasions that I am not a programmer, I am a developer. As a developer I tend to be the middleman between the graphic designer and a programmer. MODx is the tool that I use to bridge that particular gap, but for the most part I don’t write programming code.

I don’t want my comments here to be interpreted as being negative on the direction of Revolution, rather constructive in that they/we still have a long way to go with this project. I don’t know that as a non-programmer if I will be able to rapidly deploy Revolution, at least not until more of the commonly used resources are developed. Even after a full release there will still be a lot of community work to be done, on many fronts.

Right now Revolution seems to be squarely focused on meeting the needs of programmers and I realize that this may be a necessary stage in a larger process. After all, who else will develop our snippets, plugins, modules and widgets? I personally feel that if widespread adoption of MODx Revolution is to occur, it will likely be fueled by developers such as myself who tend not to create the tools (code), but who tend to successively deploy them in new and creative ways. I think that is likely one of the reasons why CMS systems like WordPress have enjoyed a broader appeal comparatively. We don’t want developers to become disenfranchised because MODx is perceived as a programmers tool with an overwhelming learning curve. Just don’t forget that we are sitting in the audience too. I hope everyone contributing to MODx keeps that in mind as this project moves forward and as more MODxpos are planned.

Monit is a free open source utility for managing and monitoring, processes, files, directories and filesystems on a UNIX system. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations… Monit can start a process if it does not run, restart a process if it does not respond and stop a process if it uses too much resources. You can use Monit to monitor files, directories and filesystems for changes, such as timestamp changes, checksum changes or size changes. You can also monitor remote hosts; Monit can ping a remote host and can check TCP/IP port connections and server protocols. Monit is controlled via an easy to use control file based on a free-format, token-oriented syntax. Monit logs to syslog or to its own log file and notifies you about error conditions and recovery status via customizable alert.

Matt “Critch” Critcher’s post, UNIX System Monitoring, from last September was written as we were just becoming familiar with Monit and had installed it on one of our more lightly trafficked servers for a testing phase.

Well, after more than a half of year of use I can say that we have been pleased enough with Monit that we have decided to install it in all of our shared environments. As Critch related, Monit is lightweight and uncomplicated to use. It simply runs in the background as a daemon. If server monitoring and management is on your plate, I would definitely recommend taking a look at it.

My Criteria

1. The calendar must be easy to integrate into the site design.
2. The calendar solution must allow for intuitive updating, by the end user, of dates/events.
3. The calendar administration area must be accessible seamlessly from the MODx admin area.

It is the 2nd point that I almost always get stuck on. Based on my experience, end users understand and can function in a calendar best when they update from a graphical, month view. Documents and lists simply do not work for them. They need to see a “calendar”.

Easy PHP Calendar

Take a look at Easy PHP Calendar. Please understand that my experience with this solution constitutes 1 ongoing project, but my experiences so far have been so good enough that I felt the need to share them.

First of all, this is a licensed product and costs $19.95 per domain. There are additional options available (which I purchased) which brought the total cost to $49.90. In my opinion it is well worth it, especially given that the site seems to have a well attended support forum.

Integration into Site Design

The calendar has a great set of supporting documents that will walk you through the installation and site integration.

What it boils down to is that you can install the calendar in a directory (let’s say /calendar/) and then using 3 separate includes (you will find these in the supporting documents) you can call the calendar directly onto the page. I placed these includes in 3 separate snippet calls on my Calendar page.

That pretty much takes care of criteria #1.

Intuitive Updating

The calendar updating is done from the events (/calendar/events/) directory and these tasks are performed from a graphical, calendar view with some slick AJAX sprinkled in for usability. It’s as straight forward to update as any calendar solution I have seen.

That pretty much takes care of criteria #2.

Calendar Administration inside of MODx

Now, it gets interesting (thank you @swscripts!). The calendar allows you to bypass the calendar login screen by placing the appropriate Username and Password in the URL. I will again refer to the supporting documentation for setting up a user account within the calendar.

I also came across this MODx forum post by goldsky which outlines how to embed another script login inside of the MODx admin.

So, following the instructions above, a “Calendar Events” module was created using the following line of code:

header("Location: ". $modx->config['site_url'] . "calendar/events/index.php?name=yourusermane&pwd=yourpassword");

Now, with the module created, all my end users have to do is login to the MODx admin, click on the module and they are editing calendar events. The events manager is less than 700px wide, so it fits great inside of the frames of the MODx admin. All I had to do was change a couple of CSS attributes and edit a couple of images and the calendar admin looked completely integrated into the MODx admin area.

That pretty much takes care of criteria #3

One of my favorite aspects of this approach is that the end user is ultimately relying on MODx for authentication and MODx allows you to use the permissions system to control user access to modules as well.

• Susan Ottwell’s Using TV Bindings
• MODx Evolution 1.0 (at) Binding

Personally, I have not used (at) Bindings extensively in my developments thus far. I do believe that they can be a powerful tool with your MODx projects. What I am planning on doing is creating a series of posts on each of the five types of data source bindings available to all template variables:

• @FILE file_path
• @DOCUMENT document_id
• @CHUNK chunk_name
• @SELECT sql_query
• @EVAL php_code
• @DIRECTORY _path_to_folder

While I always try and focus on techniques and practical implications, please understand that these posts may be as representative of research on my part as actual experience (Interpretation->Please understand if I get it wrong). I will start with @EVAL.

@EVAL

@EVAL allows you to execute php code within a Template Variable (TV). The example given on the SVN:

@EVAL return "The time stamp is now ".time();

While this use is pretty straightforward where I have found I use this particular binding is to execute snippets from inside of TVs. If you have followed some of my earlier posts on creating directories I have used directory tree containers to serve as categories that can be selected via a TV. It is through the use of the @EVAL binding that this comes to fruition.

The Quill (with this example you could also use a Ditto call) call below was placed in a TV with an input type of Listbox (Single-Select).

@EVAL return $modx->runSnippet('Quill',array('parent'=>'personnel-directory','depth'=>'0'));

What this allowed me to do was to run my Quill snippet call from within my TV. My end user could then choose one of the “Categories” from the Listbox TV when the document was edited. If a new “Category” (document) was then added by the user it would be reflected as a new, additional choice within same TV. The @EVAL provides me with what I need to create a truly dynamic TV.

For the sake of keeping this a positive post I will resist the urge to rant about the customer service I have received from Goodman Air Conditioning and Heating company.

The Background

Almost 2 years ago, in August, I purchased one of Goodman’s units through a local vendor (a one man show), had it installed, loved the unit and life was great. A few months later as the transition into winter began I realized that the heating portion of the unit didn’t function appropriately. So, we made the call to the vendor and received a service call to no avail. Well, the problems persisted and the service calls continued throughout the winter.

As spring time came around I found out that my local vendor was having health problems and was going to have to retire. He did the “right thing” and handed me off to the company above him in the distribution chain.

Well as you can probably guess, this new scenario didn’t work out very well and following a single, unsuccessful service call the owner of the new company told me he was “washing his hands” of the whole thing. He related that he was not going to lose any more money on me. I found this really odd since he had promised me he would stay with me until the situation was resolved, I was the one with the cold house, I was out about $3000 and was facing having to completely replace the defective unit out of my own pocket.

As my second winter with the unit began to roll around I started calling the manufacturer directly. To say this was an exercise in futility would be an understatement.

The Point

A by-product of my dozens of phone calls with the manufacturer was that they inadvertently called my original, local vendor who was unaware that the situation was ongoing and that I had essentially been hung out to dry.

This is the same man who had, 2 years earlier, sold and installed the unit into my house. In the mean time he had experienced serious health issues, sold his company and had retired. He had taken care of his responsibilities and handed me off to a company that should have taken care of my situation and here he was standing in my doorway. Not only has he now taken up my cause with the manufacturer, but he has purchased replacement parts on my behalf and has installed those parts on his own time. I am now confident that this will be resolved since recently learning that this problem is a “known issue”. A new computer board is en route.

For the sake of winding down a long post I just want to relate how grateful I am that someone stepped up and took responsibility for this situation (thank you Billy Trivitt).

In business, the value of good customer service cannot be underestimated. I often think people in technology struggle with customer service and treat it as if it were something elusive and puzzling. From where I sit it’s not, it’s often a matter of doing right by your customers and staying with them until they are satisfied. I know it’s not always easy, but I can tell you that from my experience it’s what your customers expect. And honestly, isn’t it what they deserve?

Whether you call yourself a user experience consultant, web developer, or content strategist; whether you design customer flows, buttons, or brands; no matter what title you hold as a full- or part-time web professional, your work shapes our future and ought to command the world’s respect. But we won’t win that respect without understanding, and we can’t hope for understanding without data and the knowledge it reluctantly yields to the patient hand and steady eye.

So, if you are a web professional go take the survey!

First of all I am not anti-Wordpress (well, maybe I am a little). It can be a good tool given the right circumstances and has actually done an effective job throughout the life of this site. I actually put this site together before I had ever even heard of MODx. Other than displaying and archiving my frequent posts I ask very little of this site and that is one of the arenas in which WordPress excels.

My Plans

I do intend to rebuild this site sometime this year. Luckily the development schedule here at Pleth is keeping these plans on the back-burner for now. I am keeping my eyes open for design inspiration(s) and am getting lots of ideas from sites like MODxClub and the MODx Showcase. If anyone has any suggestions I will be more than happy to hear them.