All articles filed under “ExpressionEngine Development”
Here’s the problem: Rich Text Editors (RTEs) are not always the best solution for a creating a diverse block of content for news post or longer, more complicated blog articles. Now don’t get me wrong, I love RTEs for many reasons; they let my clients update content for themselves with (usually) minimal fuss and effort on my part. So by and large they are a standard for every CMS in this day and age. And thanks to a recent ExpressionEngine update, a RTE is finally standard on my favorite platform.
However I’ve always felt that despite all the good that RTEs bring, they come with a decent amount of bad. Simply put, clients often mistakenly break a site’s design with RTEs. You can limit the damage through toolbar configurations that prune non-essential buttons and features, but I find myself often leaving out a more complex function such as table control. The table creation interface on most RTEs is lacking or easily misused by clients. The same goes for any kind of image use other than the very basic
Read entire article →
The standard approach to EE templates has been to have a rough equivalence between a template and a page, or a template and a content type. Templates include a header and footer, which are usually done as snippets or embeds, and some content (possibly inline, possibly using more snippets and/or embeds).
The language of “template partials” is from the Ruby on Rails world, but the concept is solid for any framework in any language. In a nutshell, the idea is this: you have one wrapper template that has containers in it, and then you fill in those containers later. The wrapper template doesn’t care what’s in the containers, and the containers don’t care about the wrapper.
“But,” you may say, “my templates are all wrappers with containers for stuff! The stuff is all different, that’s why we have to have different templates!” It’s true that the “stuff” is all different–but are the containers all different? Take a look at a typical site you’ve built–I bet that you have at most two or three markup patterns for the whole thing.
If you’re used to the typical way of working with ExpressionEngine templates, you’ll see as we go on that the template partials pattern requires thinking “inside-out” for a while. However, there are some huge benefits to switching to this way of thinking.
Read entire article →
Editor Note: In this how-to article, ProForm developer Isaac Raway shows how to create reusable form templates with his ProForm module.
One of the features of ProForm is the ability to create a single template capable of rendering any form that is designed in the module. Creating a reusable form template is simple and it can provide the same consistent UI to all of your forms, reducing the amount of work it takes to create a new form.
Goals
The basic goals for this setup is to be as flexible as possible. To this end, the essential design for this system is intended to allow multiple ways of using the same base template:
- As a full form URL - this allows us to simply link to forms that have been created in ProForm, without having to hook up anything else
- As an embedded template - allows placing the form inside of another custom template that might also do other things
Let’s get started.
Read entire article →
For the last two years I’ve been involved in the development and maintenance of large, feature rich add-ons for ExpressionEngine. These started out as primarily being internal projects for individual clients, but have since moved into my own work in the form of add-ons such as [ProForm][proform]. During this process of managing add-ons that have a rich set of features, I’ve run into a number of issues.
The add-ons that were developed internally at work were in use by multiple developers for multiple clients at the same time. Thus, each of these developers had competing and slightly incompatible goals and feature requests—features which all had to be done now, features that I had no reason (or ability) to say no to. This situation is the same that most add-on developers go through—we want to be able to say yes to all reasonable feature requests in a timely manner. Especially when first starting out as an add-on developer, one of the most important things you can do (aside from being generally helpful) is to say “yes” as often as possible.
This behavior can lead to a lot of stress. In my early experience with this kind of complexity, I was managing the same code base in multiple code bases then manually moving changes for each version between these separate projects. For most add-on developers the situation would be slightly different, but you can indeed end up with multiple versions of the same add-on. One for important client A, one for your own site, one for the default buyers.
The time scheduling issues aside (how exactly do you get two 100 hour features done in a week?) there was, at first, no way that I could manage the competing requests.
Implementing support for one critical feature would break an older feature, which had to be rewritten to use the new API provided by the first feature and so forth. At one point, things had gotten even worse with a separate developer implementing additions and changes directly to their own copy of an add-on, while I was receiving the same requests from other projects. So I’d then have to take the time to figure out how to merge those features back into the main version, while not taking other features along that those separate projects did not need.
Add-ons top of this that projects might still be running a very old version for weeks (the same is true for typical external customers), and then suddenly discover a bug that needs to be fixed in a very old version of the code. Is it easier to fix the old version, manually merge the changes into the current version, and move on? Or would it be better for them to upgrade to the latest version?
This whole situation was extremely unpleasant, and clearly unsustainable. It also wasn’t something I wanted to repeat with my own projects.
Read entire article →
One of the greatest strengths of ExpressionEngine is its flexibility, so it’s no surprise that there are usually multiple ways of accomplishing the same task. But as you continue to work more and more with EE, you sometimes find better ways of doing things, whether it’s getting something done more efficiently or with less code (or hey, maybe both!).
A good place to start when you’re new has always been with the optional Agile Records site that can be set up with a new installation. EllisLab put together the channels, custom fields and templates in there to help beginners understand how EE works and allow them to become familiar with the template language. But like anything else, you need to be able to run before you can walk, so while the Agile Records site is great for starters and allows you to build a quite capable EE site, there’s certainly room for optimization.
Read entire article →
Last year I gave a talk at the EngineSummit 2 on documenting EE projects. I’ve learned a lot the hard way in the past and I want to share the ideas and approaches with you. Hopefully you can avoid the mistakes I made.
While it’s important to supply your clients or content editors with some form of documentation—that’s not the form of documentation we’re talking about right now. We’re talking about documentation for you, the developer. Documentation for other developers who aren’t inside your head 24/7. It’s important (and I’m not the only one that thinks so) and we’ll talk about why.
Read entire article →
Earlier this year, Ty Wangsness wrote a great article over at EMarketSouth which established the basics for enabling members of a site to edit channel entries outside the EE 2 control panel. While it was an excellent primer, his article only included instructions for enabling text input and text area fields, which left a lot of us wondering how to make richer fieldtypes work. Additionally, there were some sections which might have been unfamiliar for those of us who don
Read entire article →
In this two part tutorial we’re going to walk you through building an accessory. The first part will cover creating a very simple HTML-based accessory with your contact information. The second part will build on the first using ExpressionEngine’s native code to create a fully functional contact form. Part I assumes you understand HTML, while part II will assume you know some PHP.
Let’s get started.
Read entire article →
Now that ExpressionEngine 2 is growing closer to a non-beta release, and EllisLab has published a timeline for phasing out new distributions of ExpressionEngine 1, our Vector Media Group team has been choosing EE2 for more and more client projects. One of the first difficulties we ran into when we started using EE2 was the same one we ran into when we started using EE1 many years ago—how to handle our multiple server environments gracefully.
At Vector (like many other development shops) we’re typically concerned with three primary servers: the local machines we use for day-to-day coding, the staging site where we deploy releases for the client to see and build new features, and the production server where the live site actually exists. These machines all typically have completely different URLs and file paths. While one common approach is to keep different config.php files on each server, we’ve found a single dynamic configuration file works better for our workflow.
Read entire article →
Last month EE Insider asked the readers “What do you rename your system folder to?” The responses ranged from common dictionary words to random strings and everything in between. The responders are obviously concerned about security and doing what they can to ensure malicious users or bots cannot attack their Control Panel. Let’s take a look at a simple way to secure your ExpressionEngine 2 (EE2) installation.
Read entire article →
ExpressionEngine is often used to manage membership sites, something it excels at. To help you manage member functions on the front end EE includes a comprehensive set of member templates that can be themed. You can of course choose to not use them at all and there are at least a couple of 3rd party member function options.
I want to show you how you can extend the functionality of the membership templates and/or change their default behaviour. We’re going to do that with a very simple extension. This type of extension will work in both EE 1.5.2+ and EE 2.x. The examples will use EE 1.x and the default site but you can find extensions for both EE versions at the end of this article.
Read entire article →
Every so often I come across a project where part of the spec involves a private area of content accessible via a password. ExpressionEngine gives us a number of ways to protect content out of the box.
One of the basic approaches is to restrict content to member groups thus requiring a member account for each person. If your content is not member-specific another approach is to create a generic user account and supply each individual with the username and password with which to log in.
Each approach would work in numerous scenarios. However, today I want to look at how we can utilize weblogs on a very basic level to manage password protected content very easily. Our goal is to result in a process that uses default EE functionality and that the “average client” can manage with little difficulty or confusion.
We will be using a single weblog to manage the password-protected content. The type of content is irrelevant at this point so let’s focus on how we can achieve this.
Read entire article →
Editor’s Note: Travis Schmeisser is one of the creators of the popular Structure module. Travis kindly agreed to write an article explaining how Structure came about and how it’s used.
Structure is an alternate method for building ExpressionEngine sites which focuses on pages to create hierarchy for your content. We recently released version 2.0, which is now a commercial module ($65 per site license) and includes several of the most highly requested features to date. There are tutorials and code samples for how to actually setup Structure at both Jambor-EE and the Structure site, but with this article I hope to explain some of the thinking behind the add-on and reveal why it can not only speed up your development, but make your client’s lives a lot easier.
Read entire article →
A few years ago, a client needed to list out all of the years in which there were articles on the site and allow people to click on the years and get a list of all of the articles in that year; the result being an archive of the entries by year. For those of you that have tried, you probably know that ExpressionEngine does not handle this out-of-the-box. But it does help us about half-way.
My solution was very simple. I wanted to create a list of years and make them clickable so I can access a results page with all of the articles from that year.
Read entire article →
Recently, I found myself needing to tweak how the ExpressionEngine Control Panel displays the list of comments for an entry. The editors of a website I help maintain wanted to get a more complete overview of the comments on an entry, so they could quickly tell which are spam comments and mark them to be deleted.
In the Control Panel, there is the View Comments/Trackbacks page, which you can access by clicking the “View” in the “Comments” column of the Edit entry listing. But in order to see the entire comment, you have to click on the comment link, view the complete comment text and then go back to mark the comment as spam or delete it. When each entry receives dozens of comments, this quickly becomes a lot of clicking and tremendous wasted effort.
Learn how, through a process of discovery, I found a solution to my problem that required no code, but just a couple of config.php settings.
Read entire article →