The other day I came across this older thread in the EE forums about maintenance packages for clients (EE updates, etc) and how different companies and freelancers approach this problem. That, it turns out, wasn’t the most interesting part of the thread for me. Instead, it was this paragraph from Kurt Deutscher about how he documents the add-ons and configurations for client sites so it’s easy to know what’s installed.
We store a little .txt file called aaUpdateNotes.txt in every hosting account where we work with an EE site. We list all of that site’s add-ons and who last updated the site and sometimes what version of an add-on was used (not typically though). Before we run an update on a site, we open this file and keep it open during the update incase we find something that needs to be added to, or removed from, the file for the next update. With well over 100 EE installs we maintain, that little .txt file keeps us sane when doing updates.
At a glance, Kurt knows all of the add-ons installed and perhaps any potential issues that may arise during an upgrade. It also makes it easy for people new to the site to get up to speed on the configuration. Nice idea.
Erik Reagan chimed in with a link to an add-on they’re working on called Dev Docs that allows you to have documentation within the site Control Panel. From the add-on description:
Dev Docs was born from a desire to have project-specific, developer-based documentation available within a site’s Control Panel.
At Focus Lab we have a file in each project’s repository root that is meant only for developers. This file is in Textile formatting and is meant to be the primary source of information to get “up to speed” on the project.
Has anyone been able to get EE 2.2+ working with MarsEdit? I have seen some support threads on the MarsEdit site referring to an “Invalid Access” error (which is what I’m getting) but point back to a problem with EE.
While I’m at it, how many of you even use third party tools for posting content to EE? Take the survey below and let’s find out. I’ll share the results after a few days.
Everyone’s favorite…Stephen Lewis wrote up some handy terminal commands that retreive all of the available extension hooks for a given ExpressionEngine installation. From the script comments:
A couple of useful bash one-liners for finding all of the extension hooks in a given ExpressionEngine installation. Here’s what it does:
Finds all of the native hooks, and any third-party hooks;
Sorts them alphabetically;
Outputs them to STDOUT or a file of your choosing.
Why would you need this? The most obvious reason is so you can easily find what’s available to you while developing an EE site, especially if it is one that you inherited or jumped into mid-project.
There are two commands: one that outputs the extension hooks via the STDOUT and one to a file. If you like these commands, it’ll be easier to save store them in an alias for easier retrieval or in a tool like TextExpander.
EllisLab alum and web developer Derek Allard shared a snippet he uses to have a “delete and ban” link next to comments on the front end of his site. When he gets a spam comment he can easily dispose of the problem and ban the user.
When spammers do sneak comments through my blog, I have a very simple one click* snippet to ban them similar to the way the EE forum’s “ban member” option works. Essentially, beside every comment, I have a “delete & ban” link. This saves me needing to fire up my control panel, and navigate to the proper place. It just saves a bit of clicking around.
The snippet is similar to other code you may have used before that code direct links to the Control Panel in your template and use the entry_id variable to point to the proper entry or comment.
Like LiveReload, the app is currently in beta but expected to be available for around $10 on the App Store soon. The beta will expire next week. If you’re interested in trying out another tool like LiveReload, definitely download CodeKit and give it a shot.
Not all feature requests are created equal. Some are extremely insightful and far-reaching, and improve the add-on in ways you never imagined. Most are narrow, case-specific, and don’t belong in the core product.
Extension hooks provide a means of dealing with the latter in a way that doesn’t adversely affect the core add-on.
He continues with an example of his Campaigner add-on and how allowing for custom extensions lets him, in his own words, abdicate responsibility, for special features or customizations that a developer might need for their project.
It’s well known that if you don’t change your member profile trigger word from the default of “member,” that anyone can browse to your site and see a list of members.
This recently came up again in a tweet from Ryan Masuga and what followed were some good suggestions on what to do make the issue of inadvertently exposing your member list go away.
I won’t spoil it here, so first check out the code that Low posted as a gist and then read his explanation below it. But, try to figure it out on your own first before looking at the answer.
According to EE’s parse order, snippets are parsed first, before preload replace variables. These, in turn, are parsed before plugin and module tags, so both can be used as early parsed variables. This combination makes it possible to change the content of your snippet on a per template basis. Much like embeds and embed variables, but without the performance hit.
A series of Preload Replace Variables set your template values and then the snippet just uses those variables to pull in the right data. Read the entire blog post from Low (or, if you’re like me, read it twice) to get all of the details, including some sample code.
Darren Miller put together a list of ways to protect entries from being accidentally deleted. If you’re like me, you probably already take some of these measures (like enabling versioning or properly setting member group permissions) but Darren took it a step further using a config variable and a simple extension to protect a set of entries. Very clever!
Is this necessary?
It may seem unlikely that someone would go through a double-submit confirm procedure to delete the home page of the site but somehow it does happen. So how to stop it?
A new service is available that allows you to share your code snippets with others. It’s called EE Snippets.
At first (and up until a few minutes ago), I thought the site was about sharing your Snippets (with a capital S) but it’s actually about sharing your code snippets (lowercase s). This is how some people used my EE Insider Tips service I launched in May 2009. The Tips section was never widely used but there are some great ideas, code snippets, tips, tricks and ideas in there. Here’s to hoping that EE Snippets can pull off this same idea on a dedicated site. Having a central place to share this type of information could be a great resource for the community.
Couchable put together a list of beginner EE resources, which includes dozens of links that will help you install ExpressionEngine and get started building your first site.
I’ve put together a collection of tutorials, books, articles and videos for ExpressionEngine newbies and novices. Smashing Magazine had a similar collection but it is now pretty dated being from 2008. I tried to find as many free examples as I could but ultimately I went with the resources I felt were the best, paid or otherwise. So this list will have some paid stuff but you can learn ExpressionEngine for free if you so choose.
The beauty of using Sphinx is that you can write your documentation using ReStructuredText, a text format similar to MarkDown. You can then easily generate your docs in a variety of output formats, including HTML and PDF. It also helps to keep your content separate from design, and automatically handles repetitive tasks such as generating a table of contents / navigation, and linking between your documents.
The blog post walks you through the entire process of installing Sphinx and styling it like the official ExpressionEngine documentation.
Email
Comments
Post to Twitter
Post to Delicious
