Here’s a small subroutine, written in Perl, which takes a date, and returns the number of days since this date:

#Pass date as mm/dd/yyyy hh:mm:ss and convert it to a # of days ago
sub days_ago {
 use Time::Local;
 my ($t) = @_;
 my ($date,$time) = split(/ /,$t);
 my ($mon,$day,$year) = split(/\//,$date);
 my ($hour,$min,$sec) = split(/:/,$time);
 my $last = timelocal($sec,$min,$hour,$day,$mon-1,$year);
 my $today = time();
 my $since = sprintf("%d",($today-$last)/(60*60*24));
 #print "<!--Days ago: $since - $sec,$min,$hour,$day,$mon,$year -->\n";
 return($since);
}

Example:

print &days_ago("10/01/2016 08:00:00");

Over the last few months, I’ve been working on a rather large project in Expression Engine.  This is a reflection on some of the lessons learned from that experience.

First of all, Expression Engine is meant to be a full fledged content management system and platform for custom functionality.  It allows creation of custom fields, and robust templating on the front end.

As with many CMS’s, there’s a steep learning curve for the programmers.  This included figuring out the best way to architect the use of templates, snippets, plugins, extensions, etc.  in a way that makes sense.  Figuring this out while learning EE was very difficult.  The parse order for templates was maddening to learn, along with all the nuances of the built in tags.  Due to the dynamic nature of the site, relatively little caching was used, so each page is pretty heavy with mysql queries.  Because EE has complex permissions, each template generates many database queries to figure out the final rendering.

In addition, most EE settings, including templates are stored by default in the database.  So it’s hard to track changes to the site using traditional methods (git or another version control system).  It also meant most editing was done in the Web GUI, rather than my preferred editor.

Another drawback is that database tables are all intermixed – so as a “channel” is added with custom fields, the channel data and fields are all mixed in with other channel data.  So, for example, you can’t pick out the “news” table of the database if some data needs to be imported or restored.

Expression Engine has a lot of plugins / extensions, but many are paid.  In our case, we spent maybe $100 on plugins to get the functionality we needed, but also programmed some custom add-ons that we needed.  EE also has a fee for the license if used on a commercial site, so that was a fee as well.

Overall, I see that EE can be a pretty useful CMS.  For this particular project, the functionality was perhaps a bit too dynamic and heavy for EE, though in the end we did make it work.  It did save us a lot of time by not having to build the admin backend.  For most sites, I expect EE would work fairly well, and I plan to use it again when appropriate.

Recently I started working on a rather large project using Expression Engine by Ellis Labs.  This is a CMS development system built on CodeIgniter, a php mvc framework.  At first impression, EE is very easy to use for creating data relationships (using channels and channel fields).  This facilitates building somewhat complex websites, managed through the admin interface.  It also has a robust user permission system, which makes it easy to grant access to various users.

Where EE requires a bit of a learning curve, is on the “front end” templating system.  Those looking for an easy way to throw in php code and get to work, will encounter some frustration.  Start by studying the “parsing order” of the templates, to understand how things work.  The good news is that you can add php in there to handle complex tasks, but it takes some understanding of how Expression Engine handles the template tags first.  After some study and experimenting, you can start getting things done.

EE relies heavily on modules and plugins, many of which cost money.  Overall, these can be savers and even added to the cost of Expression Engine itself, still worth the money.  However, I do wish a bit more was built into EE out of the box – sometimes it seems like relatively simple features require an add on.

One drawback to EE is the overhead required.  Even relatively simple tasks take 20+ mysql queries to build.  EE has a nice Profiler built in to see what queries are being executed.  You can cache templates to help with this overhead, but sometimes it’s laughable to see a simple task executing so many queries.

Overall, EE is a nice platform, and user friendly.  I’m sure I’ve just scratched the surface of it’s power and flexibility.  It does, however, feel almost like learning a new programming language.

One of the drawbacks to Sunshop is that you need to choose between realtime and table based shipping.

Realtime shipping methods are those that contact carriers (UPS, USPS, FedEx, etc) to get shipping quotes based on the weight of the order.

Table based shipping is where you set up ranges based on weight or order value, and charge shipping on that.   This is the more traditional methods used by catalogs and offline vendors to simplify shipping, but some online vendors like to use it as well.

I recently had a client ask to be able to use both of these simultaneously.  My solution, which seems to be working at this point, was to create a “shipping module” that ties into the shipping tables.  So it acts like a realtime method, but is actually pulling from the tables.  I also added a “Free shipping” trigger, because the client wanted to offer free shipping (using the table method) for orders over $50.  The “realtime” methods still show up, but the customer has the option of choosing their “standard” (table based) shipping rate, which is often the cheapest method.

Here’s a screenshot of the module settings:

Realtime module which pulls from the shipping tables

As I mentioned, this is still in the testing phase, but so far it seems to fit the bill.

I recently had a need for a low cost / free mailing program. Something web based, that would allow users to subscribe, then allow an admin to send out messages to the list pretty easily.

With a little searching, I stumbled upon Simple Mail List – a great looking tool, just what I needed. Written in php and mysql, and free, it was the perfect fit for my needs.

Or so I thought. Turns out Version 2 of SML is “beta”, and development stopped several years ago. Many (basic) features were not implemented, or are buggy. After installing it, and discovering all the issues, I decided to tough it out and hack up the code, finishing the features I needed.

So now I have a working installation, at least sending emails, and performing the basic required functions. Since this software is basic, it is ok with me that it’s abandonware. That’s the term for software that has been abandoned by it’s original writers. Since the software in this case is still under copyright, I can’t fix it up and “sell” it, and probably can’t even redistribute my fixes.

This highlights a problem most webmasters will face when they “go cheap”. There’s a real risk that the time and effort invested in a free software product will be wasted when that code is abandoned, bugs aren’t fixed, new required features go undone, or major security holes are discovered and go unpatched.

So be wary of using software without a business model. If the programmers can’t sustain the development, eventually they will move on to other projects.