Has a client ever said to you, “Why didn’t I get that reset password email?” Have you ever had to wait patiently for like ten minutes to get a new member activation email? Ever lose sleep wondering if your contact form is really working? If so, let me introduce you to the wonderful world of transactional email delivery services.
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
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.
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.
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:
Let’s get started.
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.
I’ve been working with the new add-on HelpDesk from Krea and I want to share my experiences so far.
This review is based on my own effort to create an integrated, single location for supporting my own ExpressionEngine add-ons. I’ve considered using a number of other existing packages, most of which do not have any integration with ExpressionEngine, as well as the possibility to build my own support add-on. I also considered building a support section on top of an existing tool such as my ProForm module. I even considered building something from scratch using ExpressionEngine’s core capabilities. While I do think that these other options could certainly do the job, HelpDesk has given be a huge head start on the job and because of it I’m nearly finished with this new section of the site after only a few days of concentrated work with HelpDesk.
If you’re looking for my one line recommendation, it is this: buy a copy of HelpDesk.
Now let’s get into some specifics.
The state of add-ons in ExpressionEngine as an embarrassment of riches. Since the launch of Devot-ee, EE users now have thousands of add-ons to browse through. As new add-ons appear which duplicate the functionality of already existing add-ons, deciding which one is the right fit for your project has become more and more complicated.
When it comes to WYSIWYG editors this is especially true. I want to do my small part to help you find the add-on for the job. In this article, I don’t pick a winner of the bunch. Instead, I want to see for myself how the most popular editors stacked up and to share what I’ve found so you can pick the right add-on for each job.
I’m reviewing the following editors, focusing on for-pay editors since I expect a different level of support when I’m paying for software.
Wygwam is probably the market-leading commercial editor for EE, with a solid history of improvements and updates. Wyvern and Expresso are newer kids on the block, with Wyvern taking a feature rich approach while Expresso seems to be aiming for a simpler and more lightweight tool set.
Before I begin I want to note that with version 2.5 of ExpressionEngine due out soon with its own WYSIWYG editor and constant updates from the developers of each of the above add-ons, I will try to keep this article as up-to-date as possible. If any errors or omissions are present, please leave a comment.
Creating and managing website forms is tricky at best and downright painful at worst. Several years ago when I jumped into ExpressionEngine development, I had become spoiled from years of using Wufoo, but in this particular project, Wufoo was no longer an option.
At the time, I found only one add-on for EE forms management, but it didn
Whenever ExpressionEngine renders a page, a variety of things happen. A parsing engine runs through the code, database calls are made, variables are replaced, conditional statements are evaluated, third party add-on scripts are run and more. While servers are amazingly fast at doing all of this, sometimes all of these processes can make a page take too many valuable seconds to load.
While it is always best practice to write your code so that the page loads as fast as possible, there are times where caching can come in and save the day by providing lighting-fast load times even for pages with a lot of processing needs. However, there are also times where caching can work against you and actually make the page slower than loading the page without it. I’ll cover the basics of caching in ExpressionEngine, including when not to do it.
Recently on Twitter someone wondered aloud how he could find freelancers that do ExpressionEngine work. It’s really not that hard and there are a few different ways to go about it. Let’s run through them quickly so you can be on your way to finding the person you need.
These tips will help you find an ExpressionEngine professional, not just a freelancer. Some of the professionals you’ll find are agencies (larger and small), not individuals.
At Republic Factory we’ve been working with ExpressionEngine for quite a few years now. We have more or less been lurking on Twitter and searching the forums now and then. Since being to EECI in Leiden the last two years and, as I write this, looking forward to going to NY in a few weeks we thought that this would be a good time to share a few tips with the community. Over the last few years we’ve gained a lot of experience building multi lingual sites with ExpressionEngine and that we feel hopefully could lend a hand to people starting out.
Being situated in Sweden we don’t have English as our first language, so most things we develop will be in Swedish and/or English. A lot of our projects also get translated to Norwegian, Danish, or Finnish. Recently, when working with a couple of bigger clients, we’ve also worked with languages like Russian, Spanish, Italian and Turkish. In this article we’ll give a few tips based on our experience of building multi lingual websites in ExpressionEngine, and introduce a couple of things to think about when starting out.
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.
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.
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
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.