Green Egg Media Blog

Undocumented CodeIgniter

Tue, 01 Feb 2011 12:09:38 -0500

Recently, I had need to write a small web app that would process hundreds of thousands of lines from a tab-delimited file into a database and run some logic against the data once a day. I immediately turned to CodeIgniter, knowing that I could rely on its speed, power, and flexibility. During the earliest tests, I was only processing the first thousand lines of the file and things were going swimmingly. The time came, though, when I was ready to run a test against the entire file, a file which contained over 335,000 lines. I had written some logic utilizing CodeIgniter’s Database Forge class to dynamically create the database tables and table structure based on information passed in the first few lines of the file, so I dropped my tables, reset my testing limits, and called up my controller.

Things seemed to be working well for the first 5 minutes. I watched as the database grew by a thousand records every few seconds. At the current rate, I calculated, it should take anywhere from 12-18 minutes to parse the entire file and return my results. But at about 9 minutes everything just stopped. The database had grown to around 150MB, and about 190,000 records, but that was all. None of my calculations had been run, no errors had been thrown by CI, and none of my debug logs had been displayed. It was clear that, for some reason, my application had just decided to stop. This was odd, as usually CI tells me why it stopped, but not this time. I checked my PHP error logs, and found what appeared to be a timeout error. Ah - an easy fix, thought I. I dropped in an ini_set() line at the top of my controller, cleared out the database, and let it fly again.

Things proceeded as before. As the database got closer and closer to 190,000 records, I held my breath. And… success? 191, 192, 193,000. It looked like things were working until suddenly everything stopped again around 195,000. There is no way I had hit the PHP timeout limit. The fact that the application had processed a few thousand more records suggested that the problem wasn’t with a particular line in the file. The PHP error log this time also didn’t have a timeout error, but there did appear to be a memory error. I was surprised at this. While the file I was processing was about 180MB, I was using fopen() and fgets() in order to avoid loading the entire file into memory. I was developing locally and already allocating 32MB of memory to PHP, so why was I running up against a memory limit? I decided to try setting a higher memory limit temporarily. I ramped up my allocated memory to 256MB. I wasn’t thrilled about this. A file parser that needs 256MB of RAM just to run? That’s not very efficient. And, it turns out, not only would it not be efficient, but it also didn’t work. I got to abut 240,000 records this time, but then I hit the memory limit again. What was going on?

Finally, I discovered what the problem was - CodeIgniter. Generally speaking, the documentation for CodeIgniter is excellent, but in this case, there was something going on that I wasn’t aware of, and that the documentation never mentions - Query Saving. This is not to be confused with query caching. That is a documented feature of CI, and one that I checked during my debugging. Query Saving is a feature of CI’s database class that stores the results of every query in memory until the controller is finished executing. As it turns out, in version 1.6.0, the ability to turn this off was added. The addition of the save_queries variable is listed in the Change Log, but as of the latest release of 2.0.0 last week, it still hasn’t made the documentation.

$this->db->save_queries = FALSE;

This single line of code in my controller allowed me to process my file, run my calculations, and generate the results I needed using only the base level of memory. For the most part, people probably don’t need to worry about whether or not CI is saving the queries, but in cases where you need to process huge amounts of data at the same time, it definitely becomes an issue. This can’t really be qualified as a memory “leak,” since CI is doing exactly what it was written to do. The question could be raised whether or not this is a required feature, though. I didn’t even know that CI was doing this, let alone that I could turn it off. It doesn’t make sense that the only reference to this variable should be in the Change Log for version 1.6.0. This is definitely something that should make the documentation for the Database Class. But until then, hopefully anyone who might be experiencing a PHP memory issue with CodeIgniter and MySQL will find this post and a solution to their problem.

Macworld Expo 2011

Thu, 27 Jan 2011 15:29:01 -0500

Having our office in downtown San Francisco has many advantages. One of these has always been our proximity to the Moscone Center, home to the venerable Macworld Expo. The Macworld Expo has been a highlight of my year since I moved to San Francisco six years ago. Sadly, I missed last year’s expo while I was on a safari in Kenya (tough life, I know), so I was doubly excited about attending this year’s event. What a miserable disappointment, then, when I arrived to discover that the 2011 Macworld Expo is nothing but a shadow of what it once was.

I knew that Apple bowed out of the Expo a couple years ago, but I didn’t realize what a significant impact this would have on the overall quality of the event. The vast majority of exhibitors were for iPhone, iPod, and iPad cases and accessories. How boring! I can see all manner of such accessories by walking across the street to the Apple Store or visiting a few websites. There really is nothing special about seeing these things in person. An iPhone case is an iPhone case and an iPad stand is an iPad stand. I guess I shouldn’t be too surprised by the lack of original exhibitors. At the first Macworld Expo after the iPhone hit the market, there was a huge influx of exhibitors with their iPhone paraphernalia, but I had really hoped that as time went by, we would start to see more innovative products at the expo. Apparently, not so.

Some of the classic exhibitors that I always look forward to seeing, though, were missing. Apparently, with Apple’s departure, the biggest exhibitors decided it was time to uproot, as well. Conspicuously absent this year were Adobe, Canon, Peachpit Press, Macally, FileMaker Pro, Microsoft (sponsored/no booth), and Ambrosia. Needless to say, it didn’t take me long to get through the entire expo when the highest quality booth was for the iGrill, a grilling thermometer for your iProduct. And even that booth wasn’t terribly exciting. I mean, you can’t operate a real grill in the middle of an expo, so the fake food on the inoperable grill served as more of a humorous sight than a reliable illustration of the product’s capabilities.

The highlight of the show for me had nothing to do with the exhibitors or the products; rather, it was when I spotted Leo Laporte and Sarah Lane from This Week in Tech doing some coverage. I ran into them twice, once at the TuneUp Media van, and again as they were walking through one of the aisles, and both times there was a swarm of people following them and taking photos. I suspect that the reactions they were getting from people at the Macworld Expo were slightly different from those they might get at, say, a Horror Movie Expo.

The lack of the major exhibitors, and the smaller number of exhibitors overall, also meant that this year’s Expo took place in only the Moscone Center West, which, I believe, has the smallest exhibition hall. In fact, the entire Macworld Expo was taking place in that single building. I remember the glory days of the expo when they occupied all three of the Moscone Center’s main buildings. At the end of the day, I suppose it was good that I went, but I’m certainly glad I got my Expo Only pass free! This year’s exhibit hall was certainly not worth a $45 price of admission. Granted, I didn’t attend any of the other functions this year, and they may have been excellent, but the exhibit hall was a complete miss in my book.

Fun with Symbolic Links, Addons, and ExpressionEngine

Mon, 22 Nov 2010 10:53:14 -0500

Symbolic links are one of those things that you probably don’t come across unless you are trying to solve a problem that they are the solution to. We like to use symbolic links to keep a handle of a number of things in a local development environment - mainly, addons.

So I guess let’s learn about symbolic links and how they can be utilized for maximum maximumication*.

What Are Symbolic Links?

We don’t really need to get too technical, but basically symbolic linking is a way to put a file or folder in multiple places. What makes symbolic links awesome is the fact that the folder or file link will act just like it is the real thing.

For instance, here is a path to an actual file inside an actual folder:

/computer/system/folder/file.php

Now let’s say we have a symbolic link of folder, and we put that into /computer/another_system/. And then our PHP code uses this file path:

/computer/another_system/folder/file.php

Bazam! That will work. So will any other files within folder. The computer thinks they are there, but they are really someone else. Magic.

Note: Symbolic links are not the same thing as file aliases. They share some features but will not work for this application.

Making a Symbolic Link

If you are on OS X, I recommend a handy little symbolic link maker tool called Symbolic Linker which gives you a contextual menu option to make a symbolic link. You can also use the terminal, but I find this way much easier.

Note: Lance would use the terminal because he likes it. He also drives a stick shift in San Francisco.

To create a link, simply open the contextual menu, and find “Make Symbolic Link”.

You’ll get a folder called the original name of the folder plus “symlink”. You can rename this file to whatever you’d like.

That’s it! You now have a symbolic link.

Example: Master Addon Folder

We all have our addons that we use over and over again, and when beginning a new ExpressionEngine site, time is wasted installing new addons as you need them.

What we like to use is a master addon folder separated out into the addon themes and the actual addon files.

For every new local ExpressionEngine install, instead of copy/pasting all of the addons we use over and over, we simply make a symbolic link to those folders and put them in the correct places in the system.

When we open up ExpressionEngine for the first time for a project, we simply go in and active the addons we need to start with, and then the ones we require as we go on. The addon installation is recorded in that ExpressionEngine install’s database, as well as any addon data. The files just do their thing.

When a new version of an update comes out, just replace it in your master addon folders, and it will update for all of your local installs. When you want to deploy, just grab the addon folder your need and upload ‘em.

Grow Your Own

Everyone’s setup is different, so your use of symbolic links will differ depending on your workflow. However, there is no denying that they are an awesome little tool for certain situations.

Just try to deny it. You can’t.

Point - made.

*Not a word.

ExpressionEngine Deployment

Wed, 17 Nov 2010 11:59:02 -0500

Last night I had the pleasure of hanging out with some of the BostonEErs crew and talking about ExpressionEngine deployment for versions 1 and 2. Since Lance wrote the wiki post on the topic, I started off of that and expanded to some more time-saving and organizational stuff with config overrides and deployment with Git.

We’ve created a little page with links to different resources and tools mentioned. If you know of anything that is not mentioned, please let us know.

Always, there was a great discussion of addons and general ExpressionEngine methods and tricks. Once the new BostonEEr’s website is up after the December 4th site building Meetup, I have a feeling it is going to turn into a great vetted EE resource source soon!

7 Features It Would Be Nice If MojoMotor Had

Fri, 29 Oct 2010 10:11:51 -0400

In the past few weeks, there has been a lot of talk about ExpressionEngine and CodeIgniter - two Ellislab products. Although starting a fire like those probably isn’t possible with MojoMotor - still a young product - we went ahead and titled this post to be as non-confrontational possible. Now, let’s get on with it.

MojoMotor, for those who don’t know, is a niftily little edit-in-place CMS from Ellislab. It was released 6 months ago, and since then has gone from 1.0 to 1.0.7 with some bug fixes and enhancements here and there.

But what about the future? Is MojoMotor fine the way it is, or does it need to innovate? Here’s our take.

Let’s think about MojoMotor’s main customer base. I’d venture to say that they are, like, ExpressionEngine’s customer base, smaller design companies. However, the emphasis is on design. They are companies that make small sites for smaller clients with limited functionality. These companies maybe didn’t start with web stuff - they maybe started with print design and moved into web. The sites MM should power are frequently described as “brochure sites”, and the companies that make these types of sites are the ones that should be the perfect fit for MojoMotor.

In short, they aren’t developers and developing isn’t high on their priority list. They need a CMS that is simple for clients and also simple to implement simple functionality. The simple part is key.

These smaller shops have a lot of choice when it comes to a CMS. Large ones like ExpressioneEngine or ModX have too much complexity for their needs, but ones like Wordpress and Concrete5 are geared more towards them.

Why? Wordpress has a litany of functionality and even though it requires some PHP know how, it is a plugin /cut and paste CMS at its core. Concrete5 is on the list because it’s the closest cousin to MojoMotor due to its in-page editing interface, similar to MojoMotor’s. It may be geared more towards developers in its promotion, but for designers who want in-page editing, it is a viable option.

MojoMotor’s strength lies in the fact you never have to touch PHP to make things work. Concrete5 and Wordpress means slogging through PHP - with MojoMotor you use Ellislab’s ever-present tag system. Add in the in-place editing and the lack of a full page control panel, and you have the basics of a very tempting system.

So why would anyone go with Wordpress or Concrete5 instead of MojoMotor if given the choice? Because, in our view, MojoMotor lacks some functionality that would otherwise sway a design firm towards paying the $50 price tag. For a small project, a designer may be willing to slog through PHP to save the cash.

We think the key to MojoMotor taking off is understanding the needs of the small site and attacking it with some key features (some unique, some not). Here’s our list of what we see as the top ones.

1. Embeddable Layouts

This is one that has been discussed since day one, and for good reason: even the least savvy designer gets DRY on some level. There are currently several resources available to be able to do this, but this one definitely should come with MojoMotor.

2. Simple Social Media Functionality

Even the smallest of the small clients now has a Twitter account, and they inevitably will want to put the last tweet on the page. To be able to do this out of the box would be a nice selling point.

3. No “pages” in the URL

Some clients don’t care, but some will wonder why “pages” is in there. It can be fixed, but there are several places in MM where “pages” is expected to be there. Removing this isn’t a selling point, but should be done for aesthetic reasons.

4. Very Basic Channel Functionality

Right now, MojoMotor is best suited to creating repeating content types for things like news sections. This makes sense. Instead of adding a new News item to a back end panel somewhere, the client can just create a new page and add the news item as it would be displayed anyways.

However, even in basic sites there are items that would be better put into simple lists that can be organized and edited by clients. If these can be worked into the page list, that would be ideal, since clients could see where those items went.

For example: you’ve got a board page with a list of people. You don’t want a different page for each person - just a blurb for each one. A nice solution would be to set up a channel with a title and a text box and give site admins a tag to display those the way they want.

5. External CSS Option

Right now MojoMotor puts the CSS right there on the page. This may be more of a personal preference, but it would be nice to be able to have that CSS be external as a choice.

6. More System Hooks for Developers

While building MojoBlocks, it became apparent that piggybacking on different systems within MojoMotor on both the PHP side and the jQuery side was simple and effective. However, there is certain functionality that is closed off to developers, like being able to make their add-on portable to EE2 through the export feature. A few system hooks would give developers the chance to plug into some important MM processes.

7. More Robust Native Contact Form

A large amount of the feature requests on the MojoMotor forums are about contact forms. The current one is pretty limited, so a few little tweaks here and there (including Captcha) would go a long way.

That’s it - some large, some small, but this is what we’d like to see in MojoMotor’s future.

In the mean time, buy our addon! Do it! You know you want to.

Introducing MojoBlocks

Thu, 21 Oct 2010 10:00:22 -0400

We here at Green Egg Media love MojoMotor. It has an interface that clients just click with, and when a complicated back end isn’t something you need, MojoMotor provides a paradigm shift into something more comfortable.

As great as MojoMotor is, it can be frustrating that its signature in-page editing feature only works for blocks of text. If you need your client to be able to update an H1 header, for instance, you are out of luck if you want to keep clients out of the layouts.

Today, we’re proud to be releasing Green Egg Media’s first foray into the paid addon community with MojoBlocks - a widget-like addon for MojoMotor that allows you to create and control editable blocks of different content - Twitter streams, RSS feeds, H tags, and more. It comes with 13 blocks and supports third party ones as well. Check out a full list of blocks here.

We’ve worked hard on making it something that is an essential to any MojoMotor install. You can find it at http://www.greeneggmedia.com/mojoblocks. It’s $15, and available for purchase today.

MojoBlocks integrates into the MojoMotor experience seamlessly - using a combination region/tag code, you create a local or global block that you then enter information into using the custom edit interface that comes up for each block:

Blocks can be very, very simple, or more complicated. For example, the H tag simple allows you create an editable H header. The Flickr block, in contrast, allows you to show photos from a Flickr set or user.

Blocks can also use MojoMotor layouts so you can control more complicated data. For instance, the RSS block returns variables that you can arrange in any way you’d like. Same with the Twitter blocks and the Flickr block.

We’ve built MojoBlocks with clients in mind. Any piece of data you don’t want your clients to be able to edit on the edit panel can be set in the tag and hidden from any meddling. You can use blocks as standalone addons too by removing the editable region div around them.

We’ve also built it with the people who build the sites in mind. We have documentation for MojoBlocks, as well as documentation for each block, and for our block syntax so you create your own.

To find out more, see a video of MojoBlocks in action, and check it out for yourself, visit http://www.greeneggmedia.com/mojoblocks.

We hope you enjoy MojoBlocks!

MojoMotor in Motion

Thu, 02 Sep 2010 10:35:27 -0400

The day before EECI2010, Lance asked me if I had any predictions what would happen at the conference. I had been thinking about this, so I said I thought Ellislab was going to announce a smaller and cheaper version of ExpressionEngine. Lance told me I was stupid and made me sleep outside with the Safeway gangs across the street from his apartment.

So I was naturally very excited the next day when Mr. Allard announced MojoMotor in a flurry of techno music and applause. Plus, I had totally called it! That’s right. I did, Lance. Deal with it.

I love EE, but for smaller projects I will use Wordpress, because EE would be overkill. In theory, that makes me target market #1 for MojoMotor, so I was eager to try it out and kick the tires. After some quality time with MojoMotor and me with some wine by the fire, here are some thoughts.

Too Many Waiters?

As Brandon Kelly mentioned on Twitter, it seems like there are a lot more add-on developers for MojoMotor than actual users.

That impression may come out of the fact that developers ride with developers, but objectively, the deluge of MM devs actually seems pretty normal at this point. Ellislab loves to play the coat rack with products - they make great core systems, and leave it to the market to flesh it out. Very libertarian of them. People can complain, but take away the coat rack, and you just have a pile of soggy coats. So now, several months after MM’s introduction into the world, it seems only natural that the activity around it is focused on figuring out what the market is going to hold, and how people are actually going to use MojoMotor. Can it sustain a $10 Twitter timeline plugin? Maybe, but only time will tell.

Changing Your Perspective

When I first opened up MojoMotor, two things struck me: the UI is very geared towards clients, and “The Publishing Engine That Does Less” is very appropriate as a tagline. As a developer of sites using EE as a tool of choice though, you can’t get into the trap of thinking “oh well, EE would do it this way, why doesn’t MM do it like this?”, because we’re working in a whole new system here.

With MM, you are in the head of the client (with a simple site) at all times, and it requires a new way of thinking - including new ways of thinking about how content is managed and updated.

That being said, remember that MM is a very, very young product. The news that Ellislab recently snatched up Dan Horrigan after he took a few victory laps of MM add-on brilliance says volumes about where MM is going in the future. Until we get there though, I think a truly useful MM install needs a booster chair.

MojoMotor Install Must Haves

So you have your $49 MojoMotor installation and you need to build a site. I would recommend getting these before you dive in:

ShowMe (Free)

One feature I was actually quite surprised wasn’t built native into MojoMotor was the ability to nest layouts. ShowMe, by Loic Sharma, solves this problem handily. I just couldn’t bring myself to pay $7 for the commercial version, Pieces, for such a basic CMS must-have.

Cartographer (Free)

Chances are if you are working on a site that needs MM, your client will be asking about SEO at some point. While you are hooking them up to Webmaster tools, you can use Cartographer to easily generate an XML sitemap. By Zack Kitzmiller.

MojoBlog ($15)

We all know what a complete disaster having clients edit a list of items is in just a WYSYWIG text area. As such, you gotta have your content streams. Mr. Jamie Rumbelow comes to the rescue with MojoBlog, an essential to any MM install.

Analyze (Free)

You know what? Why not.

MojoPHP (Free)

We all need a little PHP once in a while. Dan Horrigan to the rescue with this one.

Other fun add-ons are M’Sync and Tom Myer’s awesomely paranoid Backdoor add-on.

The Future

Like I mentioned earlier, the addition of Dan Horrigan to the MM team says a lot about the fact that Ellislab isn’t going to let this product sit on its initial version laurels. In the future it would be nice to see some features like embedded layouts built in so we don’t have to install an add-on for that.

It would also be great to have a native MojoMotor Add-on admin panel, so we can use features like Phil Sturgeon’s MojoVariables in a more useful way (it should be a very simple implementation, of course). Yes, there is an add-on admin panel but we need a native one if it is going to be implemented consistently.

The Value Is There

Bottom line: if you take our list of MM essentials and tally them up with your MojoMotor install, you get a grand total of $65. That is $235 less than if you bought a commercial ExpressionEngine license, without any EE add-ons. $65 and you have a lot of power to create a small and effective site using some of the most essential tools you use on ExpressionEngine.

That to me, depending on the project, is a no-brainer.

Moving from Development to Production on EE 2

Mon, 30 Aug 2010 09:00:26 -0400

There are several guides for server migration under ExpressionEngine 1.x, but so far nothing on migrating ExpressionEngine 2.1. This guide is based our our own experience of moving a site from a development environment to a production environment. We have tried to capture as many aspects of the move as possible, but every EE site is different. You may find that we include steps which you can omit, or you may discover that there are additional steps you need to take.

This tutorial assumes that your development environment is on a different server than your production environment. If this is not the case, you can still use much of this tutorial, but note that some steps may not apply, or may only partially apply.

It can’t be said enough - before you start making any significant changes to your database or file system, backup your data!

STEP 1: Backup your data

Creating a backup of your data is always a good idea before undertaking any major changes. Moving a site from a development environment to a production environment is considered a major change, so make sure you have a backup of your data in case something goes terribly wrong.

STEP 2: Synchronize Templates (if needed)

If you are not saving your templates as flat files (i.e., in the file system), skip to Step 3.

If you are saving your templates as flat files, make certain that your templates are all synchronized before beginning. If your templates are not synchronized, you might encounter some trouble in the production environment, particularly if the last changes you made to the templates were made to the flat files and not in the Template Manager.

To synchronize your templates, in the Control Panel, go to Design > Templates > Synchronize Templates.

If the Sync column has all green check marks, you’re good to go, otherwise, sync those templates that are out of sync until they are all checked green.

STEP 3: Export your Database (MySQL dump)

If you have access to phpMyAdmin in your development environment, login. If not, you will need to export your database using a different tool. Some hosts provide different methods of exporting your data through a hosting control panel, or you might need to use the command line if you are using a local development environment without phpMyAdmin. This step will detail how you go about using phpMyAdmin.

After logging in to phpMyAdmin, select the correct database from the left-hand column. Depending on your environment, you may have only one database listed. Once selected, you should see something like this:

Make a note of the Collation method listed. It will usually be utf8_general_ci, but if there is another collation used, like latin1, make a note of this. When we reimport the data, you will need to use the same collation, or things might break entirely.

Click on the Export tab. You will be presented with a number of options.

Verify that all of the tables are selected, that you have selected to export as SQL, that you are exporting the Structure of the database, and that you are exporting the data, itself. Verify that the “Save as File” box is ticked, name your export, and click Go. This will generate an SQL file that you must save somewhere. We will need this SQL file to import it into the production environment.

STEP 4: Create a Database on the production server

Now you need to create a new database on your production server. This is generally done through a Database Manager in the hosting control panel. When you create the database, you will either create a MySQL username and password at the same time, or you will assign an existing MySQL username and password to the new database. For security reasons it is a good idea to have a separate username and password for each production database. When creating the database, make a note of the following items, as you will need them later:

MySQL hostname or IP address (provided by your host)
Database name (generally you select this, but sometimes it is assigned)
MySQL username
MySQL password

Now, login to phpMyAdmin on the production server. You should see your newly created database in the left-hand column, but it will have no tables assigned to it. Select the database and then select the “import” option on the screen that appears:

You will now be presented with the import options:

Select the SQL file that was created in Step 3. Verify that the same collation is being used. For most database imports, you should uncheck to box under Partial Import. If your SQL file is very large, it might exceed limits set on your server. In the example image above, the limit is 7,168 KiB. Your server may vary. If your SQL file is smaller than the size limit, you should always uncheck the Partial Import box. If your file is larger than the limit, you can allow partial imports. Partial imports are beyond the scope of this tutorial and will not be covered further.

Once set, click the “Go” button to upload and import your data. If successful, the left-hand column should populate with all of your tables.

STEP 5: Migrate The File System and Set Permissions

First, if you are deploying an ExpressionEngine site to a production environment where a non-ExpressionEngine website currently exists, backup the data on the existing production server. Do not simply delete the existing file system or overwrite it. If something goes wrong, you will not be able to recover the old production system.

Now, make sure that the development file system is backed up. (You already did that in step 1, right?)

You have two options for migrating the development file system. The fastest is generally to archive the contents of the development server (zip or tar, for example) and upload the archive to the production server where you will extract the contents. However, if your hosting control panel does not give you access to create an archive (on the development server) or extract an archive (on the production server) this option may not be available.

If you can’t create an archive on the development server, but you can extract one on the production server, you can download the file system to your local machine and create the archive locally.

If you can’t extract the archive on the production server, you will need to upload the file system as folders and files, which will take longer.

Once you have all of the files in place on the production server, whether you used the archive method or the individual files method, you must verify permissions as follows. If you are using a Unix server (or Unix variant, like Linux, OS X, FreeBSD, etc.) you must set the following files to 666 (or equivalent write permissions on your server):

/system/expressionengine/config/config.php
/system/expressionengine/config/database.php

And the follow directories to 777 (or equivalent write permissions on your server):

/system/expressionengine/cache/
/images/avatars/uploads/
/images/captchas/
/images/member_photos/
/images/pm_attachments/
/images/signature_attachments/
/images/uploads/

If you are saving templates as flat files, you must set the relevant directory (and all its subdirectories) (usually located inside /system/expressionengine/templates/) to 755.

If you have any other special directories or files that require permissions, set those now. For example, several add-ons that manipulate files, such as ED Image Resizer, require that the directory for sized images be set to 777.

STEP 6: Update database.php & config.php

Now, grab those notes about the database, and use them to update the contents of /system/expressionengine/config/database.php.

Next, open /system/expressionengine/config/config.php and set the correct URLS for the following variables:

$config[‘cp_url’]
$config[‘base_url’]

STEP 7: Update paths in the Control Panel

If all has gone well so far, you should be able to login to your control panel at http://yourdomain.tld/system/ If th.e server balks, try http://yourdomain.tld/system/index.php If yo.u still can’t get the Control Panel, something has gone wrong. I hope you backed everything up.

Once you have logged into the CP, there are several places where you need to change paths. If you don’t know your new server path, there are several ways to find this. The easiest is to look for the _SERVER[“DOMAIN_PATH”] variable in Tools > Utilities > PHP Info:

Once you have your path information, update it in the CP. Here are the most common area you’ll need to update:

Admin > Channel Administration > Channels > Edit Preferences > Path Settings (URLs for each channel, and any other URLs set. Even if these are just set to the default, they will use the old server paths, and should be updated for clarity and developer hygiene.)
Admin > General Configuration (three URLs and one path)
Admin > Content Administration > File Upload Preferences (both path and URL for each upload destination set)
Admin > System Administration > Image Resizing Preferences (this is only required if using ImageMagick or NetPBM - if it wasn’t set before and everything was working as you expected, it doesn’t need to be set now)
Admin > System Administration > Emoticon Preferences
Admin > Security and Privacy > CAPTCHA Preferences
Design > Template Manager > Global Template Preferences (only required if you are saving templates as flat files)

STEP 8: Update paths in templates, CSS, JS, and third-party add-ons

If you used any server paths or absolute URLs pointing to your development environment anywhere else, you need to update those now. Common things to look out for:

<base href> tags in templates
Hard-coded absolute URLs in templates (should be rare - if you’re using these, try {site_url} instead)
paths set in CSS or JS - especially JavaScripts that aren’t being parsed by EE. EE tries not to parse JS files, so if your JS needs a path, you probably had to hard code it
paths set in third-party add-ons, either in the CP, or sometimes in one of the files living in the file system (like ED Image Resizer, which required the plugin file to contain two paths)
images or files included in entries if you hard-coded the links, or if your WYSIWIG editor hard-coded the links (if you have a lot of these, you might try using the SQL Manager in Tools > Data > SQL Manager or the Search and Replace in Tools > Data > Search and Replace)

STEP 9: Verify Template Synchronization

If you aren’t saving templates as files, skip to Step 10.

If you are saving templates as files, verify that you can properly sync your templates using the Synchronize Templates feature. If you can’t, you may need to delete the directory specified in Design > Template Manager > Global Template Preferences from the file system and recreate that directory again on the production server. This is only true on servers that have ownership issues with the your specified template directory.

STEP 10: Clear your cache

Clear all Caches in Tools > Data > Clear Caching

This is to verify that there is no residual cache data from the development server.

STEP 11: Load the site

If all went well, you should be able to navigate to http://yourdomain.tld/ and everything will work.

Good Luck!

The Egg, Rehatched

Thu, 26 Aug 2010 12:00:32 -0400

“We’re almost ready to hatch.” So read the splash screen at greeneggmedia.com on March 1, 2008, the day we opened our proverbial doors for business. Indeed, the Green Egg Media website took a back seat for the first few months due to a number of client projects which had already been booked before our first official day as a California business, but finally, on June 5, 2008, our first site broke through the thick green shell and hatched. It was a thing of beauty. For any of you who have seen our business cards, the original website looked something like those. Unfortunately, I made the mistake of ordering way too many of those cards, and even two and a half years later I still haven’t found the bottom of the box.

After the first site launched, it didn’t take long before revisions for a new site were underway. Already by July 7, 2008, a new design mock-up was done which sparked a flurry of new ideas and design concepts. Of all of the design concepts that we explored in July and August that year, I am most disappointed that we didn’t launch the design that had an animated cartoon rocket that took users from one page to another. Opportunity missed. It wasn’t until October, 2008, that we finally launched a new design that was completely unlike anything else we had explored, but there it was. How long could we really be content with that site? Not very long, apparently.

By March, 2009, we already had new, finalized designs for the third version of the Green Egg Media website. Our third site was, without a doubt, better than the first two, and it served us quite well. But, as history has shown, nothing lasts forever. This brings us to today: August 26, 2010. It has been almost 18 months since we last redesigned the website, and almost as long since we last even thought to update it with recent, relevant content. So what better way to update content than with a complete redesign? As such, today marks the launch of the fourth edition of greeneggmedia.com.

Yes, we’ve rehatched, but this time it’s more than a just a new face. Today we’re proud to announce some very exciting new features of the Green Egg Media website. First and foremost, we’ve built the new site on ExpressionEngine 2. We’ve been working with ExpressionEngine for some time now, but until today, all of our previous sites were custom CodeIgniter applications. Given the power and versatility of EE2, though, we decided that it made the most sense to build our own site in EE.

Second, we are introducing the blog, which you are reading at this very moment. Previous iterations of our website were of the “set-it-and-forget-it” variety, but with this new site we will bring you regular content relevant to design and development. If you follow us on Twitter, you already know that we’re serious when we need to be, and amazingly fun at all other times. You should expect nothing less from this blog. For example, in the blog we’ll feature exciting company news, such as the official Green Egg Media book-of-the-quarter. The last book we selected was “Egg Monsters from Mars,” which instilled such fear in Adam that he had to assume the fetal position under his desk. (By the way, if you don’t already follow us on Twitter, you should. Or I’ll cry.)

Next, we have unveiled our code area. Here other developers will find useful code that we have written for ExpressionEngine and CodeIgniter. We’re constantly working to improve the CI and EE communities, and one of the best ways we can think of to do this is by making our work available to all of you.

Finally, we’re also showcasing side projects. These are projects that Green Egg Media is involved in outside of our regular client design and development work. Side projects can range from trade-specific blogs, to video productions that we’re producing, to virtually anything else that doesn’t fit somewhere else on this site.

We’re really excited about our new site, and we look forward to hearing from you here on the blog, or via our Contact Form.