jQuery UI is very solid and comes with a lot of great functionality. For anything that's not included there is usually a plug-in to fill the gap. ShiftEdit has some quite demanding requirements especially for the tabs component. For most sites showing a tabbed layout with various content is probably all they need. For ShiftEdit on the other hand, we need to be able to add and close tabs, drag tabs between panels, and right click them to see a tab menu. One thing I found lacking was how jQuery handles tab overflow. By default if you add too many tabs than can phystically fit then they will fall onto the next line:
The existing plug-ins I found either implement a scroller or a dropdown menu. This is ok in principle but I found the implementations to be quite buggy in the latest jQuery UI - especially when you throw in drag-drop re-ordering. I really wanted an implementation that uses Chrome's method of shrinking down tabs so that they fit in the tab bar. I couldn't find anything like this so I created a new plug-in.
This method has usability advantages as there isn't the disconnect when using a menu or scroller and accessing the tab. It's also easier to implement, as I don't have to worry about positioning any extra buttons or do anything special for tab re-ordering. Throw in a jQuery animation and it looks pretty swish too.
I hope somebody finds this useful as it's good to give back after making use of so many great jQuery plug-ins.
15/11/2015 permalink | Posted in web development | 115 Comments »
ExtJS is available under a commercial and a GPL license. As they are using GPL and not AGPL I felt secure being able to use their framework legitimately without needing a commercial license. Even so I looked into purchasing a commercial license to support the company that provided a vital part of my app. Having looked through the license agreement I was taken aback by this line:
"you are not allowed to create applications that can be described as a development toolkit or library, an application builder, a website builder, or any application that is intended for use by software, application, or website developers or designers"
Seeing as this is exactly the kind of service I am providing I decided the commerical license was not a viable option. It struck me as odd that this would even form part of the license agreement, what are Sencha afraid of?
Using the GPL version has it's limitations. No access to the latest point release, so you end up having to maintain a bunch of hacks, even for bugs you yourself have reported. The framework code is not available on Github so nobody external to Sencha can contribute code back to the framework.
Some time later Ext JS 4 came out. A fair amount of code rewriting was required to be compatible with the new version. ExtJS had provided a useful compatibility mode to ease the transition but it still took some time.
Since then Ext JS 5 and now 6 have come out. The upgrade path looked anything but straight-forward and the most feasible option would be to start again and then import bits of my old app. It'd near enough require a total rewrite.
I noticed that newer Ext version were no longer being made available on Sencha's CDN. It seems the GPL version continues to be an outcast.
I looked again at the commercial license. This time the minimum purchase is 5 licenses, even if you only need one. It seems to me that there is something rotten happening at Sencha. They used to have several well-known developers (Ed Spencer, Brian Moeskau) who I respected but have since moved on. They even took developers off the team page and replaced then with corporate shills. They seem to be run by money men who are only interested in working with big corporations. I know longer see ExtJS as a viable framework for indie developers.
As I needed a rewrite anyway I looked into modern alternatives to ExtJS. I've decided to go with jQuery UI. While the jQuery UI components are very bare bone, they can be extended and should do everything I need. In fact the project should end up being a lot lighter with a smaller memory footprint. As I'm starting again from the ground up, it's a great opportunity to re-organise the code. I'm using requirejs to compartmentalise code into a more logical structure.
I'm excited about working with jQuery for a more demanding project as I find it very elegant to use. I'm keen to work with the jQuery UI crowd and hopefully contribute some good extensions and fixes back to the community.
I intend to post more updates as I work on the rebuild.
12/10/2015 permalink | Posted in web development | 0 Comments »
If you build a website and complied with the triple-A standards, how would you expect it to look in all the different browsers? Exactly the same? You followed all the rules, dotted the i's and crossed the t's right? Wrong! Different web browsers have varying degrees of compatibility with the W3C specifications. IE6 is the worst offender that is still commonly used today. So even if you design your HTML to W3C standards it does not mean it will render correctly in IE6. So what do you do, well you can take those things out and limit your creativity or you could look at various tips and tricks, hacks and what-nots to get IE6 up to speed. But these are the sorts of things that can prevent your site from validating. But who really cares about validation right, surely the most important thing is the end user. And the end user is looking at your website using IE, Firefox, Safari and Chrome - they are not using the W3 validation service.
So does this mean I hate the W3C. Not at all, in fact as a web developer I really appreciate what they do. They make the rules for the browser vendors to follow. They create common ground so that surfers can get a consistent experience regardless of which web browser they are using. The more consistent web browsers are - the easier it makes my job. The browser vendors build browsers according to the spec. Then I build websites according to what works in the browsers.
07/10/2010 permalink | Posted in web development | 0 Comments »
Following on from last week I've been working on more ways to make websites faster and save precious bandwidth.
I've also enabled gzip compression in PHP. Because of shiftlib this was easy to add to multiple sites at the same time.
To enable gzip in apache you need to do the following:
# nano /etc/httpd/conf.d/mod_deflate.conf
Then restart apache:
To enable expiration headers in apache - you need to do the following:
Then restart apache:
Up until now my main PHP thumbnail script has generated images on the fly. PHP is so fast that it doesn't take very long even for a page full of images. However when you have lots of visitors all those clock cycles add up and there are significant savings to be made. My thumbnail script works by pointing the image source to a php script - and passing in the filename as a variable, e.g
There is a big problem with this. Because it's pointing to a php script the cache headers won't work. You could use the php header function to send the correct cache headers but I still suspect that it won't cache as well as a regular image. There is another problem - search engines won't know that it's an image - especially if it's in a link. They would just think it's a regular php page. So they will go ahead and pull down a bunch of images without needing to.
So my new approach is a little different. I have a function that checks if there is a cached thumbnail before creating one if necessary. It then returns the image tag of the resulting thumnail. e.g.
I checked the web-stats of some of the busier websites that I host. There was a significant chunk of bandwidth being used by search engines - around 10%. Search engines will index an entire site several times over a month - but they shouldn't have to pull down every single image. This may be related to the thumbnail issue outlined above but I also have taken another precaution. I've created a robots.txt file and am now preventing access to uploads folders and thumbnail scripts and anything else that a search engine doesn't need. I may need to add an exception for google image search, but for the time being I will monitor it and see how it goes.
18/07/2010 permalink | Posted in web development | 0 Comments »
Server bandwidth has been a tad high recently - so I decided to profile some of the busiest sites using the excellent resource measuring tools in Google Chrome. The most obvious culprit on the sites I looked at was AJAX libraries like Prototype, jQuery and extJS. I needed to speed this up, now I already know about Google AJAX libraries API - so that seemed like a good place to start.
Google AJAX libraries API provides an interface to load remote AJAX libraries using Google bandwidth. Google automatically handles caching and minifying to make the files load as quickly as possible. This is great but there are a few limitations.
You have to declare which version of the library to load. I manage a lot of sites and generally I just want the most efficient, up-to-date version without having to update many different websites.
So I've added a PHP function to ShiftLib called load_js(). You can send this function an array of libraries and it will load the most up-to-date versions using Google AJAX Libraries.
I've also added support for lightbox and extJS - which are not supported by Google AJAX Libraries. My function will also detect if the page is running under SSL and subsequently load all the scripts by HTTPS if it is. It loads all the scripts in the correct order to avoid conflicts and works out dependencies - e.g. lightbox requires prototype to work.
So instead of having a block of code like this:
I now have:
12/07/2010 permalink | Posted in web development | 8 Comments »
Database queries can very often be the bottle-neck that slows down a webpage. If you have a busy server with lots of sites or lots of webpages it's not always apparent which database queries are causing the problems.
Logging slow queries
A good place to start is by logging slow queries. You can do this by adding the following lines to your MySQL config file (usually /etc/my.cnf)
Create the log file and give it write access:
You will then need to restart mysql:
After a while the log file should start to fill up with a list of queries that have taken longer than 1 second.
Adding indexes can have a dramatic affect on speed. You should look at the table joins and WHERE conditions of the query to see where indexes could be used.
Take these examples.
Adding an index to the "name" column will significantly improve this query.
Adding one combined index for "name" and "surname" will help here.
In this case I would use a unique index for the email column. Unique means that the email address can only appear once in the table. This is much faster than a regular index and also enforces the database integrity.
Note that indexes take up space and slow down insert/ updates - but this is generally a small price to pay for much faster select statements.
Correct field types
It's worth looking over the database structure and seeing if a TINYINT could be used instead of an INT. Or an ENUM instead of a VARCHAR. Also check the size of the VARCHAR columns and adjust accordingly. Check if INT fields should be UNSIGNED. An UNSIGNED INT can only be positive (>=0). Unsigned INTs should always be used for ID columns - and again this helps with your database integrity. You may need to run "OPTIMIZE table" before you see any benefit. You probably won't see a drastic improvement - but these little changes all add up.
Joins are an expensive operation and should only be used when absolutely necessary. Check the fields you are selecting and your WHERE conditions to see if you really need each join.
Only select what you need to, so if you only need to fetch an ID instead of doing:
And you can use limit to prevent searching of the entire table.
Try not to include MySQL queries in PHP loops - you might be able to get the same outcome using a join or a sub-select at a fraction of the time.
This should be enough to get you started. For even better performance you could try tweaking MySQL itself or upgrading your hardware.
07/07/2010 permalink | Posted in web development | 13 Comments »
PHP 5.3 comes with two very important features: Namespaces and Closures.
Namespaces allow you to compartmentalise your classes, constants and functions.
This can prevent conflicts between your code and third-party code. Third-party code could be a blog or a forum that you've installed on your website.
I had a conflict when adding wordpress to a website. Wordpress was complaining that the is_email function already existed. This is because is_email is a function in my library that I use all the time to determine if an email address is valid. My only choice was to either rename one of the functions - or get wordpress to use mine. Changing anything like that in wordpress is not feasible - as any changes I make would need to be redone every time wordpress is updated. So I ended up renaming my function to is_valid_email and then going through all my code and referring it to the new, less snappier function name. Not an ideal solution by any means.
Namespaces would have been a much better solution as you can effectively say - this is my code and this is wordpress and put them in their own little namespace box so that they can't kill each-other.
Closures / Anonymous functions
Here's the same code with an anonymous function:
The hello function is only ever going to used as an event handler - so we don't need to give it a name. This means that the code is more concise and we haven't had to spend time thinking of a good function name.
This is an example of how they are implemented in PHP - taken from the PHP manual:
10/03/2010 permalink | Posted in web development | 32 Comments »
As a freelance developer sometimes it's tempting to take on every bit of work that comes along. But a short term gain now is not always in your long term interests.
Some projects are not well thought out/ rely on existing code or have too many strings attached.
Not well thought out projects
Sometimes I'm asked to quote on building a site like website X. Or quote on a project after a 5 minute conversation.
This is never enough to go on. At least you want some sort of written up project brief which you can turn into a workable spec which outlines all the pages and functionality therein. At best you might even be given a sitemap or detailed project plan. The more information the better, because once a quote is agreed there can't be any room for misinterpretation. Otherwise the project will drag on and on and become less and less profitable.
Projects that rely on existing code
You should take extra care when taking on a project that relies on existing code. If the project was done by a previous developer - make sure you have a good look over the code and see what condition it's in before you commit. Sometimes it's quicker and easier to redo a site than it is to work with badly written code. This will also help avoid any security issues with existing code and make the whole project a lot easier to maintain.
The other type of projects with existing code are those that rely on drupal/ mambo etc or other off-the-shelf systems like shopping carts.
In some ways these systems are worse. They are inflexible, require more hacking, often low-budget and a nightmare to maintain. I personally avoid them like the plague.
The only exception I make to this are forums like phpBB which are self-contained and can be cordoned off from the rest of the website.
Too Many Strings Attached
Don't compromise on your policies without serious considerations. Don't back down over your payment terms and read contracts very carefully before agreeing to them. Make sure you reserve the right to re-use code that you've developed. And don't agree to any personal liabilities.
That's it for now, feel free to leave a comment.
23/06/2009 permalink | Posted in web development | 6 Comments »
Very often PHP coders will output HTML like so:
This causes the following issues:
It's harder for web designers to work with
It gets in the way of syntax highlighting
It gets in the way of code-assist
You have to watch out for quotes.
So what's the answer. Well here's how I do it.
This approach involves a few more PHP tags but it solves all of the above issues. It works better in IDEs, is easier to read and maintain and helps keep PHP and HTML separate.
06/06/2009 permalink | Posted in web development | 3 Comments »
PHP is a very flexible language. Maybe too flexible. There are a lot of ways to skin a cat. Some ways are a lot better than others, and some have security vulnerabilites.
After a day of monitoring web development forums it's quickly become apparent that beginners get very confused about MySQL.
In this post I will focus on inserting data into a database. There are a few different ways to insert data into a database. Imagine we are capturing some user data. This is how I would do it:
Now there are a few things going on here:
The escape function is VERY important as it will prevent basic sql injection attacks. A lot of beginners forget this.
You should avoid printing error messages to the screen, as this can aid hackers. So try not to use "or die(mysql_error())". Instead use a custom error handler as demonstrated above.
18/05/2009 permalink | Posted in web development | 11 Comments »
I've recently joined a bunch of web development forums to see if can help PHP rookies and simultaneously get my name about. I don't tend to post questions in forms that much because I can normally figure stuff out or find the answer on google. So instead I'm looking to answer some questions and play a more active role in the PHP community.
These are the forums I've joined:
Of these so far sitepoint seems to be the most active and interesting.
17/05/2009 permalink | Posted in web development | 248 Comments »
After working on several projects with web designers it soon became apparent that after I'd added my programming it became very difficult for the designer to maintain. What I needed was a way to separate the programming from the design. It was around then that I came across Smarty - PHP templating system. At the time Smarty was an official sub-project of PHP which gave it a big boost over it's competitors in my eyes.
I used smarty in a few projects and quite liked it. It was like learning a new language as there is quite a lot of new functions to learn. Some of these functions are great but some are just equivalents of PHP functions because PHP can't be used directly in a template. I also had some issues to overcome - like making sure certain pages didn't get cached and that all variables had been correctly declared - or else they would not appear on the page.
I found that altho the pages were easier to edit than what I had done before they still had a few issues for designers. A lot of designers use dreamweaver and were put off when the CSS and images weren't displaying in design mode because the template was in a different path. Also whereas before PHP blocks would be hidden behind a PHP icon, now the Smarty code was fully displayed and looked like page content and could be mistakenly edited. The idea behind Smarty code is that it's supposed to be easier to understand for designers. In practice I've found that designers probably don't fully understand code however it's presented / and nor should they need to.
Smarty added a bit of bloat to my projects and also became another thing to maintain - having to upgrade all projects with the latest version of smarty and hoping nothing breaks. And a few times I'd been caught out when projects had moved servers and I hadn't checked the permissions on the template cache folder - which isn't always obvious to spot.
So because of these issues, I stopped using Smarty and developed my own templating system which is a lot simpler and is all done in PHP and doesn't require you to learn a new language. It's friendlier for designers and has some built-in SEO goodness like search engine friendly URLs, automated page titles and dynamic sitemaps. I've since re-written all active projects that used Smarty to take advantage of this new format.
On reflection Smarty was not the best solution for me. However it did teach me the fundamental importance of keeping code separate from design. I also learned from it some fantastic functions for dealing with html drop-downs and date/time selections which I've subsequently adapted and use in my own projects. So while I wouldn't recommend it, I've definitely benefited from the experience.
08/05/2009 permalink | Posted in web development | 0 Comments »
There are a fair few choices of server side languages to choose from the grandaddy perl to relatively new trendy languages like ruby or python. Somewhere in the middle is PHP.
PHP is open source and has been ported to many operating systems including linux. windows and mac. This open source philosophy extends to a wealth of free resources including tutorials, classes and components. There is some fantastic open source PHP software such as phpBB, phpMyAdmin and JpGraph. This is in stark contrast to the closed source ASP which many basic components are paid-for.
PHP is all about rapid application development. There are a number of built-in extensions and out-of-the-box you can use PHP to manipulate images, send emails, execute shell commands and much much more.
The hardest thing about PHP is learning all the different functions - there are thousands of them. And they don't all follow the same naming convention e.g. addslashes() / str_replace(). Luckily the php.net website is at hand. It provides comprehensive easy-to-follow documentation on all functions with clear examples. There is also a lot of crucial information and sample code in the comments.
In summary PHP is a great choice. It's free, well-supported and easy to learn. Long live PHP!
07/05/2009 permalink | Posted in web development | 23 Comments »
There is quite a bit of hype surrounding open source systems like
I've looked into them but have so far avoided using them.
I'm not against these systems per se. I think they are good for
non-profits or sites with limited budgets. They allow peeps who
aren't web developers to create and manage their own fairly
sophisticated web-sites. But this is also part of the problem, it's
almost like Frontpage for PHP. It allows them to create a functional
system very easily. But as soon as they have to customise it in a way
which wasn't originally intended; they start hitting brick walls.
Either that or the systems are over-complicated to use.
So what's the alternative?
Well here's what I do. I've developed a generic/ flexible CMS system that I use for a back-end on all my CMS projects. The front-end is always coded from scratch. This gives the designers complete freedom to design the site anyway they see fit and I integrate the CMS into their design. Over the years I've developed a core library that speeds up development by taking care of ecommerce/ account logins etc. But at all times I've got complete control over the functionality.
some interesting quotes from a slashdot article on drupal:
Recently we managed to phase out our corporate drupal-based site. It was close to impossible to upgrade from Drupal 4.x up to 5.x (and 6.x) because of custom modules and we have no human resources to recode someone's crap from version to version every year.
Don't even talk about "Joomla" and "Mambo". They're a nightmare to maintain, and a royal pain in the ASS for building an SEO friendly site with friendly URL's that don't look like a matrix reloaded computer screenshot.
The problem is, the moment you make the mistake of thinking you're going to add fields to modules, apply true custom skins to them, rearrange their content, etc. on top of an already largely built framework, it very quickly falls apart. You get two choices at that point: add on systems that kinda sorta give you some of what you need but still leave you limited or hacking in to the source code that's really not built with that kind of customization in mind.
I spent months with Drupal, tracking the boards, reading the docs, listening to many podcast series. But I came away feeling that, despite its many features and modules, it's quite kludgey.
And this one:
I'm so tired of taking over sites where the former "developer" used a Drupal or Joomla installation.
It is inevitable that the requirements of a custom web app will eventually exceed the capability of these systems. Knowledge of a particular CMS does not a developer make! These are tools in a toolbox and should be used as such. I hate it when people sell themselves as freelance "programmers", but really they only know how to use a particular CMS. So lets write a book and encourage this behavior - bluagh..
I still have some websites lingering around that use Joomla but I am very much dissociated with that CMS, infact any CMS nowadays. I find the issues that these systems bring to the table far outweigh any little added productivity that a small group can sustain. There are teams of script kiddies from Asia and elsewhere scouring online websites for these systems to prove just how easy they are to hack into. If you have an online database with confidential client information, you are in trouble.
The problem with popular CMS systems today stems from the tight coupling of back-end architecture and front-end architecture.
06/05/2009 permalink | Posted in web development | 45 Comments »
PHP code blocks are usually started one or two ways. Either by using the full PHP tag: <?php or the short-hand tag, which is just <?. The short-hand tag allows you to do: <?=$var;?> which is the equivalent of <?php echo $var;?>. This is a lot more concise and when you develop as much as I do it's a real time-saver and is more readable.
PHP short tags are enabled by default in PHP although they are officially discouraged because of a potential collision with xml. XML blocks start with <?xml
The other arguments against short-tags is portability. Some web hosts won't have short-tags enabled by default. This is pretty easy to remedy - either by editing the php.ini file or adding a htaccess file.
Now some PHP purists will say that anyone who uses short tags is error prone or antiquated. This is simply unfounded as short tags are not deprecated and as long as you are aware of the shortcomings; won't cause you any more errors..
PHP6 is going to be a major shake up to PHP - a lot of things are going to go like safe-mode / register globals etc. But it would appear that short-tags will be staying. Probably due to the sheer amount of code and rebel coders that rely on them.
Now for super-standards-compliant perfecto projects it may be sensible to use the full PHP tags. But for standard every day use, short tags are ok - so don't let the nay-sayers put you off.
01/05/2009 permalink | Posted in web development | 0 Comments »
About meAdam Jimenez is a freelance web developer who has been professionally developing websites since 2000.