With the themes I sell on Theme Forest, I get a lot of customer support questions regarding basic CSS issues. I understand that some people really are just looking to get whatever free work out of the theme author they can for that whole $15 the author just made off of the purchase when they simply drop a laundry list of CSS changes they want “help” with into the item’s discussion board. However, I also know that many theme buyers out there are legitimately trying to solve these issues themselves and they just can’t figure them out. These people want to learn and I’m sure they don’t like buying that WordPress theme and then feeling like they can’t move forward until the theme author finally responds to them telling them how to change the dimensions of the logo or how on earth that “one title” in that in that “one box” is styled.

So, now I’m going to give a very basic example of how you might go about making a minor CSS change with Firebug. Keep in mind that while I’m using my Theme Forest theme, Complexity, as an example, these strategies can be applied to anyone making any kind of CSS changes to their site. So, whether you’ve just bought a WordPress theme, or you’re diving into your partner’s sloppy code, these methods should work for you.

Download and install Firebug

Start by making sure you’re currently using the Firefox web browser. Then go to the Firebug website and download and install the addon.

CSS Example: Changing that random title in that random box

When you’re wanting to make a simple change, it’s not always so simple. It’s not enough to look at the HTML source code and determine what’s wrapped around an element and then know what CSS to apply in order to change it. You need to know exactly how that element is being styled in the current CSS files, so you can either change it, or override it.

Looking at this example, let’s say you want to change the font size of the titles of these three homepage boxes.

Many people might start by looking at the HTML source code and then determine that the title is wrapped in<h2> tags. However, this isn’t enough to tell you how to make your CSS change because you don’t know how the original developer coded it in the CSS style sheet. Sure, you could guess, but if you’re trying to make a bunch of CSS customizations, this is going to slow you down and take up a lot of your time.

So, let’s use Firebug to figure it out really quickly. Simply right click on the element you want to check out and click “Inspect Element” to open up the Firebug panel on the item you’re interested in looking at.

Now you’ll be shown exactly what CSS is being applied to that element and what file that CSS is located in.

Now you know that the CSS that controls this element is located in style.css and looks something like this:

#default-home-widget-area .widget h2 { font-size: 22px; }

From here’s it’s easy. You can either change that in style.css or write some CSS that overrides it somewhere else.

On my themes, and like many other authors, I generally have a place on my theme options page where you can put in custom CSS. So you might do something like this to change that above element to have a 15px font size instead of its default 22px size.

Why is this all so important?

The reason why Firebug made this so quick is because we needed to know the exact CSS declaration. With the above example, custom CSS like this would have had no effect:

.widget h2 { font-size: 15px; }

It needs to be like this or it wouldn’t have overridden the original CSS:

#default-home-widget-area .widget h2 { font-size: 15px; }

Because of how “cascading” stylesheets (CSS) work, anything that’s more specific or drilled down is going to take precedence over something that’s more broad.

It’s also a good idea to watch this helpful video walk through on all of the basic features of Firebug. You can do a lot more than just make simple CSS changes!

So, needless to say, I’ve been churning out a lot of WordPress sites recently at the agency. In this post, I’m going to talk about that last step you take in delivering your shiny, new WordPress site to your client filled with all of their content.

Generally, you’re not going to build the website on your client’s live domain. I usually develop the initial WordPress theme and put in whatever parts of the content I have at the start of the project locally on my computer using MAMP. Then I’ll transfer that site to a dev server where the client and everyone else my agency can view it. After a billion rounds of edits and changes, it’s finally ready to go live, and so then it’s transferred to the client’s live domain.

In creating all of these sites, it’s absolutely crucial to be transferring WordPress correctly. Your concern should be developing your client’s website and not struggling with elementary things like installing and moving around WordPress. If you’re new to the process of moving WordPress, don’t worry. I’m going to explain in it detail. I also would suggest that you practice moving WordPress a few times to different servers. After a few times, you’ll get the hang of it, and see how easy it is. If the first time you’ve ever moved WordPress is the time when you’re putting you client’s site live, you are putting yourself at some serious risk for embarrassment.

Keep in mind that if you’re simply moving your personal WordPress site a new server, all of the following steps are the same.

The Quick Version

To start with, here is a quick version of the process of moving your WordPress site from one to server to another. Even after you’re familiar with the process, it’s not a bad idea to have a checklist of all the steps you need to take sitting by your desk.

If all of those steps weren’t clear, don’t worry; I’m going to explain each one. In the following steps, I’m going to show some screenshots from when I transferred the demo site for my Complexity WordPress theme from my local computer to my live demo website.

The Long Version

Step 1: Export a copy of your dev site’s MySQL database as an SQL file.

The first thing I do is make a copy of the dev site’s database. Login to phpMyAdmin on your development server and export a copy of database.

When you do this, make sure you are actually within the database. You should see all of the tables of your WordPress installation as the screenshot below shows. Then, click “Export.”

Next, configure your export file as I have in the screenshot below. Make sure you have all tables of your database highlighted on the left side. Also, make sure you have the “save as file” checked at the bottom. Click “Go” and a copy of your database should be saved to your computer as an SQL file.

Step 2: Open this SQL file in a text editor and do a mass find and replace of your dev site URL with the new server’s URL.

Open up the SQL copy of your dev site’s database you exported in the last step in a decent text editor like Dreamweaver, Coda, Textmate, Netbeans, etc. Avoid using a default text editor that comes with your computer (like Notepad with Windows, for example). With large files, sometimes screwy things can happen.

Do a mass find and replace of your dev site’s URL with your new server’s URL.

This is a very important step. If you do this properly, all of your hyperlinks throughout your entire WordPress site will linked up properly on the new server (i.e. manual links you put to other pages in your content, links to images you’ve uploaded, custom links you’ve used in the menu builder, etc.)

I personally use Coda for Mac OSX for all my coding, and below is an example of how to do a mass find and replace with your database SQL file in Coda.

I know Dreamweaver is much more popular, and so here is a screenshot of doing the exact same thing in Dreamweaver.

Step 3: Make a copy of your dev site’s files so they’re ready to upload to the new server.

I personally feel it’s a good idea to actually make a copy of the files of your dev site because if you screw something up, it’s nice to know you have a fully functional dev site still sitting somewhere. So, make a copy of all files, meaning your entire installation of WordPress.

If you have your website locally because you’re using MAMP or WAMP, make a copy of the files. If you have your dev site on a live web server, download all the files to your local computer.

Important Note: Confirm everything in your wp-content directory gets copied. This directory contains everything crucial in the actual configuration of your WordPress site – Themes, Plugins, and Uploads.

Step 4: Create a MySQL database on your new server.

If you’ve created your dev site, I’m going to assume you know how to create a MySQL database. So find where your new server’s database management is (usually in cPanel or whatever similar software your web hosts uses) and create a new, empty database and assign a new username and password to it.

Step 5: Configure your dev site copy’s wp-config.php file with the new server’s database information.

Within the copy you made of your dev site’s files, open up the wp-config.php file and put in all the information from the database you created in the previous step on your new server – database name, database username, database password, and database host.

This is the typical process of installing a WordPress theme, which I’m sure you’re already familiar with. However, it’s a good idea to have your wp-config.php file all ready to go before you upload your files so you can minimize the amount of downtime on the new, live server before the site is actually running.

Step 6: Upload the dev site files to the new server.

Now that you have a copy of all your files, you’ve made sure everything in your wp-content directory is there, and you’ve configured your wp-config.php file, you’re ready to upload!

So, use an FTP client and upload all of your files.

Simply uploading all of your files via FTP is the most common way of doing this process, and it’s perfectly fine to do it that way. However, I do have a tip if you want to be a little more efficient.

Archive all of your files into a ZIP package and then upload that ZIP file to your new server. Most hosting accounts have an interface like cPanel with some kind of File Manager interface, which you can log into and then extract the ZIP package. And if you’re a little more saavy, you can shell in with an SSH client, and unzip that package really quickly.

There are a few of reasons why it’s a good idea to ZIP the files first before you upload the files. When transferring a WordPress site that has been fully developed, chances are you have a lot of files (i.e. your plugins, uploads, themes, etc). These files will take a while to upload and it’s much faster to upload an archived ZIP package.

Other than just the files taking forever to upload, another issue arises sometimes when uploading a lot of files at once through an FTP program. Often, your upload will time out or there will be a temporary connection loss to your server, or something breaks the upload for whatever reason in the middle of the uploading process. When you’re dealing with your client’s new, live site, you don’t want to be wondering if you’ve missed any files. By uploading a ZIP package you can be a lot more certain that you’ve gotten everything successfully to the new server on the upload.

Also, if you are uploading the files one at a time to your new server and someone happens to visit the live URL, they’re going to be presented with funky error messages because WordPress is only half there. This is actually more for the benefit of your client. Clients are always excited about their new website and will keep checking the live domain like an eager schoolboy on Christmas morning, waiting for it to be up. When they see some PHP error, they are going to freak out and call you. You’re going to have to then explain to them that you’re still in the process of uploading files and working on the site.

Step 7: Make your uploads directory writeable (permissions 777).

If you want your client to be able to upload images and files via the WordPress admin panel, make sure you remember to make the uploads directory writeable (permissions 777) on the new server.

You can go in do this with any FTP client.

Step 8: Confirm your database is linked up correctly by going to the new site and seeing the Install WordPress screen.

Now that all of your files are uploaded and in place, it’s a good idea to make sure the files are there and that your wp-config.php is connected properly to your new database. So, if you visit the URL of the new site, you should be forwarded to WordPress Installation screen because your new server’s MySQL database is still empty.

If you’ve inserted something incorrectly in your wp-config.php file or the new server’s MySQL database was not setup properly, you’ll know because you’ll see WordPress’s database connection error.

Step 9: Import your dev site’s SQL into your new server’s database.

Now you’re going to need that SQL file you created back in steps one and two.

Login to the new server’s phpMyAdmin and navigate to the database you’re using. If you’re unsure how to do this on the new server, make sure to contact the web host’s customer support and ask.

Click the Import tab. Then, select the SQL file from your computer and click “Go” to import the data.

You should see a message that lets you know your query was successful, and you should see that your database is now populated with all of WordPress’s content.

Now if you go back to the new, live site, you shouldn’t be forwarded to the WordPress installation page. You should see your website!

Step 10: Login into the WP admin of the new site and go to Settings > Permalinks and click “Save Changes” so an .htaccess file with permalink structure is created on the new server.

At this point you should be just about finished. If you had permalinks setup on your dev site, and you start clicking around the new, live site, you might initially notice that none of your pages are showing up when navigating away from the homepage. What the hell? Don’t fear! There’s a simple answer.

Basically, your WordPress database is configured with the correct permalink structure, however the needed .htaccess file that gets created back when you setup your permalink structure on your dev site isn’t there anymore on the new server. So WordPress is trying to navigate to the correct links, however, your server isn’t setup to handle them yet.

The fix is easy. Login in to your WordPress admin panel and navigate to Settings > Permalinks and simply click “Save Changes” so WordPress can create a new .htaccess file on your new server.

With some web hosts, WordPress will give you an error message when you try and save your permalink settings, telling you that it couldn’t create an .htaccess file. This just means that you need to go into your web host’s file manager and create a new file, name it “.htaccess” and then make it writeable (permissions 777).

With that said, there have been times where I want to slap every browser upside the head, but with a little focus and research, there’s always a fix!

I see a lot of novice developers, beginning authors on Theme Forest, and developers just learning how to code tableless designs complain that their website works perfectly in Firefox, but then completely breaks in Internet Explorer.  It’s one thing if your website is totally destroyed in IE6. I get it. It takes a lot of practice to understand why IE6 does what it does, and none of us will ever fully understand what Microsoft was trying to accomplish there. And even though I do always try and support IE6, I don’t expect everyone to do that. It’s a personal call from developer to developer.

With that said, there’s really no reason why a website you develop would work in the latest version of Firefox, but then be totally destroyed in the latest version of Internet Explorer. This just means that there are clearly some things that you don’t understand, and there’s absolutely nothing wrong with that; this is how you learn. Just don’t bitch about it in a forum and curse IE because you don’t understand basic web development concepts work, like the box model, for example.

Oh the box model, you say?

Yeah, I just threw it out there! We’re getting closer to the reveal of the Bobich Law of Browser Compatibility.

For those of you that don’t know, the CSS box model describes the boxes that are formed around elements of content in a Web page. Every element in a Web page is in a box or is a box. The boxes on Web pages are constrained by rules defined by the CSS box model.

Well, I already know about the CSS box model, so what’s your point?

This is all nothing new, right? Many developers know all about the CSS box model, but choose not to think about it until they see a broken website in IE.

I used to have a partner at the Advertising agency I worked at that was so adamant about W3C compliance that he would always say with his nose pointing up to the sky, “I design for W3C standards only. IE comes later.” Then after the site was essentially finished, he’d view his broken site in Internet Explorer and start going through and making changes in a stylesheet called with an IE conditional statement. No offense to him if he ever reads this, but while neatly commented, his HTML/CSS was quite sloppy and he spent way too much time trying to configure this sloppy CSS file for IE.

But would you believe there’s a way for your website to have totally W3C compliant CSS while still having all of your boxes be the same width in both Firefox and Internet Explorer?

So what the hell is it already?

It’s so simple, you’re going to be embarrassed I had to tell you, but this is a rule I’ve developed for myself and I always follow whenever I code anything. And finally, this is what I’ve dubbed the Bobich Law of Browser Compatibility:

Easier said than done, Jason! I need padding and widths on all my divs, how will I ever trudge on?

Don’t worry, friends. I’m not going to just throw out something as mind blowing as the Bobich Law of Browser Compatibility without giving you some helpful information on how to work with it.

Keep in mind that many developers might disagree with the methods I’m about to share because they could be said to add too much cumbersome HTML markup to your site, but I don’t care. If you’ve purchased any of my Theme Forest themes, you’d know that I write extremely clean HTML and CSS that looks almost identical in most browsers.

Basically, on all of my major layout divs that need a width, I also add in a nested div that will have any padding or borders associated with it. Here is an example of a box that will be 300px no matter if it’s viewed in Firefox, Safari, Chrome, Opera or even Internet Explorer.

Here’s the code that produces the above box:

<style type="text/css">
.example-box {
  width: 300px;
  background: #f2f2f2
}
.example-box .pad {
  border: 1px solid #ccc;
  padding: 10px
}
</style>
<div class="example-box">
   <div class="pad">
    This is a box that's 300px wide in all browsers with 10px of padding and a 1px border.
   </div><!-- .pad (end) -->
</div><!-- .example-box (end) -->


Now, I’m not saying you need a div inside of every div in your website. If I were saying this, I’m sure Nick La would slap me across the face! Nick La runs the super awesome web design blog, WebDesignerWall. He’s even written a post about not having nested divs all over the place, and this is why I made sure to say I do this only on my major layout when I need to. So, I definitely agree that wherever possible, as Nick stresses in his post, that you should avoid extra divs.

For example, say you have some HTML like this:

<div class=”box”>
  <h2>The Title</h2>
  <p>The content…</p>
</div>

If you have a set a width to that “box” div and you want there to be padding within it, there’s no need to put another nested div inside when you can just add padding to the <h2> and <p> tags.

The idea here is to follow my silly Bobich Law of Browser Compatibility while still trying to write as little code as possible.

While we’re at it, here’s another quick tip for writing easy-to-manage CSS that will help:

In my opinion, putting widths on every div within a div means that most likely you don’t fully understand how margin and padding work or you’re not planning out your design very well before coding. Before you code, you should have a plan. You should know that if you have a column that’s 300px wide with 10px of padding and you place a nested div inside of that, it will automatically fill 100% of the width, resulting in a div that’s 280px. That’s a very basic example, but you could see how this could get really confusing and out of hand if you have many boxes within boxes and you’re not planning these things out.

These are some very elementary tips, I know, but they might help many developers who are either just learning tableless design or just that have never thought of the obvious, I guess.

I’m really excited about the release of Complexity. I’ve been working on it since WordPress released the their version 3 beta a few months ago, and I’ve specifically designed it to work with WordPress 3. Moving forward from my previous WordPress theme, Barely Corporate, I had some new goals in mind. With Barely Corporate I was new to WordPress theming and I tried to add in a lot of really custom features, but with Complexity I really wanted to add as much functionality while still keeping everything as WordPress intended. I tried to limit the amount of unnecessary custom meta boxes and options wherever possible. This was especially easy with the all of the possibilities of WordPress 3. This all factors in to the primary goal, which is for the buyer to install the template and have their website up and running as quickly as possible.

Complexity Premium WordPress Theme – 12 in 1

Complexity Premium HTML Theme – 12 in 1

I’m going to briefly talk about some of the cool features I’m excited about. You can read even more about the different features on the theme’s live demo.

Navigation Menus

Custom navigation menus were a huge leap forward for WordPress with the release of version 3.0. Of course this theme takes advantage of WordPress’s all new menu builder to give you the most dynamic CMS experience. No more are you restricted having pages on your main menu. Now you can mix and match whatever items you want.

Custom Post Types

This theme takes advantage of custom post types to give you the simplest way of managing your portfolios and slideshows.

Post Thumbnails

This theme supports the “Add Featured Image” feature. This was actually introduced in WordPress 2.9, but it’s still worth mentioning. It used to be a pain in the ass to incorporate post thumbnails into a WordPress theme. A lot of authors still use custom meta boxes that create unnecessary custom fields. That’s all a thing of the past.

2 Homepages

I originally tried to design a homepage that was a little different than your average layout with the Complexity HTML theme, but I didn’t get a lot of sales. So, with the WordPress theme, I decided to go back to the ol’ slider with three boxes underneath. However, I did keep the option for both homepages to be used.

Timthumb Image Cropping On/Off

This was actually a surprisingly significant update.

Timthumb is a popular image cropping plugin by Darren Hoyt that has been built into this theme. It’s utilized within the homepage slideshow and the Portfolio. This means that you can put any size image in and it will cropped and scaled by your server to fit into your website.

However, as most people that have used TimThumb know, there are rare occasions that some of smaller web hosting companies do not have compatible servers or have security issues that block methods that TimThumb uses.
Also, while many people like the ease of uploading an image and having it re-sized for them, many people that have the capability to edit their images prefer to have more control over what shows up on their website. They like to get their image cropped and looking perfect before uploading.

That’s why a convenient on/off feature has been added into the theme’s Theme Options page.

By day, I’m a web developer at a fancy schmancy advertising company, but by night I’m a web developer for the people! With my personal projects and templates that I make from home, I follow a much less structured workflow. With no budget or deadlines, I’m free to spend as much time as I want adjusting my drop shadows and gradients until they look just right. Unfortunately, for now I’m stuck in the real world and my day-time job calls for me to be much more organized and productive with my time. Some times it feels like I’m “cookie cutting” out websites day after day at work, but it is what it is.

Now keep in mind that when I make a website at my agency, I don’t deal with clients, I don’t budget finances or hours, I don’t write any content; there are different departments that handle all of these things. I simply design and develop. So when I get a new docket on my desk this is the basic process of how I bust out a website over the course of a few days. I’m going to skip all the boring pre-meetings, planning, and approvals throughout the process and just share the good stuff.

1. Design

I do all my designing in Photoshop. Sorry, I’m not much of a Fireworks guy. I’m in love with the 960 grid system. I start most of my designs with the 12-column Photoshop file you can download from their site. With that said, I’m way too anal about my CSS to use their CSS framework, so I’m only down with the 960 grid system for the initial design.

I can honestly say that I do not consider myself much of a “graphic designer.” Sure, I can make clean, minimalist designs with good typography and proper spacing, blah blah, but when it comes to actually adding hardcore graphical elements I head to Graphic River and drop $3 here or there. If you’re ever at a loss for design ideas, don’t hesitate to search the web for inspiration or even buy a few graphics from a site like Graphic River. You find a stock image or another website design you like, you start off copying a few things, and before you know it, you have a completely different masterpiece that you can call your own. By the end, you won’t even see a resemblance between your final product and whatever things you originally got inspiration from.

I’m very meticulous with my measurements. I use round numbers whenever I can. For example, I wouldn’t ever make a header section that is 88px in height; it would be 85px or 90px. I’ve found that the more you measure out in Photoshop, the more symmetry you plan into your design, and the more round numbers you use, the easier things are when you take it into development. I’ve worked with many artists who think my OCD for pixel measurement is overkill, but I think I just have more going on in my mind when I’m laying it out aside from simply how it will look.

Even in a time crunch, I still attempt to be at least somewhat organized with my layers and layer groups within my Photoshop file. A lot of the times I’m rushed by my agency due to a low budget or a time crunch, however the client, the account managers, the creative director, and the “higher ups” will always want several edits. So keeping an organized Photoshop file that I’m familiar with always keeps making edits a breeze.

Also, many times a site is designed for me by one of the other graphic designers, in which case it’s often done in Adobe InDesign. If you know anything about web development, I’m sure I don’t even need to voice my frustration with this. Designing something for a world of pixels in a software that creates for a world of print is a definite sin in my bible. Either way, it is what it is. You gotta to roll with the punches. So, a lot of times, my “design” phase consists of taking an InDesign file and creating an actual workable psd file that I can develop from.

2. Development

If you haven’t figured out by now from the screenshots, yes, “I am a Mac.” I’m not exactly proud that I jumped on the band wagon of locking myself in for a lifetime of addicting, overpriced computers and gadgets, but none the less, I couldn’t help but get sucked in.

I have to say my absolute favorite thing about being a Mac user is the software, Coda. I’m really obsessed with Coda. I finally got my ad agency to dig deep into their pockets and find me the $99 for a Coda license about 2 months ago. Right away, I setup all my current projects in Coda and told Dreamweaver to step off.

Also, I now use PHP for every project even if it’s a static site. In my opinion, there’s just no reason not to have simple header/footer includes on even the most simple websites. We have a web server in our offices that all of the web developers work off in order to have all the websites in a place where any of us can access them. But, at home, I’m 100% MAMP…. Once again, this is another treat of being a Mac user. For those of you that don’t know, MAMP is a free software that allows you to run PHP/MySQL locally on your mac for development purposes.

Now getting into it, the development process is my favorite. After all, that’s why I’m writing more about it than any other of the other steps! I am an absolute CSS dork. I’m always looking for tips, tricks, and ways to improve my CSS and make my HTML markup as minimal as possible. The development process is the one time at work that I can really put my headphones on, jack up the Pandora, and crank it out. With other web developers assigned to their own projects, there’s absolutely no one else that can stand over my should and critique. Believe me – the day an account manager looks over my should and says, “Um, you’re definitely gonna want to hide the overflow on that div,” is the day I will quit. No worries on that one, though. When I’m in a sea of code, no one bugs me. It rocks.

I make so many small, low budgets websites at work, that it’s really important for me to bust these things out as time efficiently as possible. I start my sites with a little starter template I keep on my desktop. It includes the basic folder structure and some initial files I use for almost every website. This is the case whether I’m making a static site or WordPress theme because I always make WordPress themes completely from scratch. Sure, I’ll copy and paste snippets in later on, but the initial process always starts with a single static HTML page.

I almost always have already planned out the HTML markup in my head while I was laying out the design in Photoshop. This is another reason I’m so meticulous with my measurements in Photoshop. Besides, most sites I do are not mind blowing Internet phenomena; they pretty much all have your standard elements, and that’s another reason why it’s easy for me to sort of formulate a plan of attack in my mind.

So, I continue by saving out the images I need from my Photoshop file in the images folder I already have made in my starter template. This is a random tidbit, but I do not “slice” in Photoshop. I think it’s silly. You can do it if you want, but don’t insist that I do it. Then I write out all of my HTML markup. Next I write out all of my CSS.

I’ve gone through this process so many times that I pretty much have a good idea of how what I’m coding is going to appear in all the browsers I plan to support (generally IE6+, FF2+, Chrome, Opera, Safari). So, with following a few simple rules I’ve made for myself, I go forth coding and only viewing what I’m doing in Firefox.

I think I’m actually going to write a blog post later on about my simple rules I’ve made up for myself to stick to while coding in order to avoid conflicts with different browsers… And by different browsers, I mean all browsers versus the IE browsers!

3. W3C Compatibility

This is usually very painless for me and a quick task. There’s not much to say here. I open up the website I’m working on in all the standard browsers and check to make sure they look passable. They generally do.

4. Internet Explorer Compatibility

It always used to be a pain in the ass checking my sites in Internet Explorer, but I’ve slowly began to make my life easier and easier over the last few years. I have a few simple rules that I follow while coding my sites, and usually when I open it up in Internet Explorer, it looks how I intended it to. If I ever have Internet Explorer issues, it’s due to some javascript error that I can usually find and fix pretty quickly. I know I make this sound very easy, but keep in mind that none of the sites I’m creating at work are very “out of the box.”

You also may be wondering if I code for IE6? I did say it earlier, but yes I do. Even though every web developer thinks IE6 is the Satan’s spawn of a browser, I still support it. Why? Click here for my IE6 rant.

To accomplish this dirty deed, I use VMware Fusion, which allows me to run Windows 7 on my Mac. Then I open up the handy IETester and give whatever website I’m working on a quick spin in IE6+.

5. Post it for review

After I’ve cycled through the same songs on my Pandora channel a crap ton of times because I’m too picky with adding variety and thumbing songs up, it’s time to post the website live on the Internet at a top secret location now that I’ve finished it.

Keep in mind that most sites that I “finish” are far from finished. It’s rare that I was given everything I needed when I was tasked with actually developing a website. Generally more copy and content is still to come. The sitemap is in for a big change from it’s original mockup. Images are to be replaced. Decisions that were made before will inevitably change.

So, I email that top secret web address off to my creative director, and I assume it travels through about 20 different people and the client inevitability? I’m not really sure. But low and behold, a month or so later I get back edits. But it’s good that I write consistent, neat code because I can always pick up a project right where I left off no matter how many other sites were in between!

It’s really peculiar when I compare the amount of websites I work on with the amount of sites that have actually gone live… Anyway, that’s my workflow process. I know that kind of turned into more of a “Confessions an Agency Web Developer” post, but I hope you found it interesting!

Feel free to comment below on your own personal experiences and methods.

How many times have you heard that around the web development community? I have to be honest. I’m really tired of hearing everyone’s bitching. If you’re really making a cutting edge website, then don’t bother with supporting IE6. I think your website’s users can appreciate a simple upgrade notification or something similar.

Okay. So here’s my answer on the subject as a web developer at an advertising agency:

I do support IE6. I have to. I live in the real world where not everyone is a web developer. A world where people don’t all have new computers. A world where not all people upgrade their computers. A world where many people don’t even know what a web browser is. The point is, in most cases, you’re going to have clients that have all kinds of Internet users. Whether you like it or not, you have to support them.

Did I mention I live in Anchorage, Alaska? Yeah! Needless to say not all clients have Windows 7 installed with the latest version of IE. Not to mention we have tons of clients that serve smaller, remote parts of Alaska.

It seems that any time I make a site that doesn’t work in IE6, I hear about it. I generally have an account manager come to me, and say, “The client says the site doesn’t work. Can you fix it?” This is code for “it doesn’t work in IE6.” If you think supporting IE6 is ridiculous, try explaining to your account manager when they tell you “it doesn’t work” what this mystical IE6 thing all the web developers are bitching about is. Prepare yourself for a nice, “Can you fix it anyway?”

For me, telling an account manager that I’m not going to fix a website because we shouldn’t be supporting IE6 is like telling a child that Santa isn’t coming this Christmas. They don’t understand, they don’t like it, and they want it anyway.

Now here’s my answer as a Theme Forest newbie:

Basically, I support IE6 if it’s convenient for me. I try to abide my simple CSS methods that generally make my sites look similar in all browsers. However, in the end if it doesn’t look perfect in IE6, I really don’t sweat it. If something looks really screwy and I don’t have to spend much time fixing it, sure, I’ll do it.

There are definitely a lot of times that when I’m making sites at home that are more “out of the box” I run into a complete mess in IE6 at the end, and you know what? I say screw it. Believe me, I’ve never seen a drop in sales on a template for it not working in IE6; that’s for sure.

It’s here. . . finally!

Well, they finally released the beta version of SocialEngine 4 yesterday and I have to say I was excited to get it installed and play around with it. I was also excited to start designing and coding all new themes for it.

I installed it and started clicking around the admin panel and figuring how it works. I have to say that initially I was kind of in shock at what I found – a little pissed actually. For the user, it’s totally awesome, but for me, the theme developer, not so much. Basically, within the admin panel you control all of the elements throughout the pages. You drag elements around to different areas of the layout sort of like widgets in WordPress. Imagine a WordPress theme where literally every element of the website was a widget in a widget area, including the header and footer areas.

So, what does it all mean for me?

It means I can’t touch any HTML markup! Yes, I could probably figure out ways to sneak in little changes in the markup if I dig into the core files, but I don’t feel like that would be smart in making a theme that is supposed to be easily installed by customers. In other words, I’m stuck with just selling a CSS file with an images folder.

Moving forward. It’s really not that bad.

After getting over the initial shock of what these changes mean for my online store, I’ve had some time to think about it and I’m actually a little excited. Developing themes for the new SocialEngine 4 is going to be like the old days of creating CSS templates for CSS Zen Garden, a showcase of designs all based on the same HTML markup.

And after going through SocialEngine 4′s HTML markup, I have to say that they did a really good job. It truly leaves many possibilities to change the look of your site with purely CSS.

Also, a big plus with how SocialEngine 4 handles themes now is that they really are classified as “themes.” In the admin panel there’s actually a section where you can manage all of your uploaded themes, and with the HTML markup never changing, they’re basically like interchangeable skins. Flip one off and another one on with no effort.

As I let it grow on me a bit, I’m starting to like the idea. This is so much more intuitive than previous versions of SocialEngine where I had to sell the customer template files that they had to upload to their site, overwriting the old files. I’d have to write in the instructions, “remember to back up all files!” So, I guess those days are over.

A new business plan for MysocialEngine.com.

I am, however, going to have rethink the way my site operates with these significant changes to SocialEngine. Currently I sell themes for about $40-$80. I have full demos where customers can click through an entire installation of SocialEngine with a particular theme in place. When the customer purchases a theme they are given a pretty big zip package with everything they need. I only kept about five themes on the site at at time because keeping them compatible with SocialEngine every time it was updated was a real pain.

With the hassle of always keeping my themes up-to-date with the current version of SocialEngine seemingly gone, I’ll finally have a chance to produce a lot of themes and really pack the website with a true variety of SocialEngine themes. It’ll also be a lot quicker to develop the themes as they are just going to be essentially a single CSS file combined with a folder of images. I’m sure as I become more familiar with SocialEngine 4′s HTML markup, I’ll be able to speed up the process, as well. However, one bad thing is that I’ll have to get rid of online demos because it would be too easy for people to steal the themes.

Overall, I have to say that I think this all means I’ll be lowering prices for my themes, too, which I think everyone will enjoy!

Downloads

Stylez WordPress Theme

Stylez PSD Theme

Why start a social networking website?

Well, the basic idea here is pretty straight forward. Any website you you can build that gets a lot of traffic is worth money. Typically the idea behind making money with a social networking website would be through advertisements. You build up a social networking website filled with Los Angeles singles surfing around, posting comments, checking messages, etc, and then you hit ‘em with ads.

Also, you’ll find that it’s becoming more and more popular to attach some sort of social networking feature to your existing website. Adding that “community” aspect to your website is a sure way to retain some visitors and give something to come back for. This concept is definitely nothing new. Webmasters have been tagging on forums to their websites for years, but now it’s pretty easy to do even more than that.

So, how is it possible for me to start a social networking website?

There are a few scripts out there that allow you to create social networking websites, but SocialEngine is by far my favorite. SocialEngine is a PHP/MySQL script that’ll give your website a ton of community functionality with things like member profiles, messages, comments, forums, photo galleries, blogs, music sharing, and a lot more. SocialEngine can be used as a stand-alone website or can be used perfectly as an addition to your current website.

Unfortunately SocialEngine isn’t free. For a single license, SocialEngine will cost you $250 for the core software. Then you can add on various plugins such as Photo Albums, Blogs, Groups, Chat, Videos, Classifieds, Polls, etc. These plugins generally cost between $30-$40 each. It doesn’t stop there. There are many 3rd party developers out there that sell plugins, as well. There are also websites where you can buy SocialEngine templates.

Has anyone made it big with SocialEngine?

RetailMeNot is a great example of a company who was able to cash in by using SocialEngine.