conticreative

Entries from October 2006

Memory_limit problem in Joomla with Community Builder

October 28, 2006 · 11 Comments

Check out my new website where I am now maintaining all my blogs.
Thank you.
Marco Conti

Working with Joomla! is very exhilarating and there is a tendency, when you work on your site, to want to test all the different modules available. Some of them have some really crappy code, others are simply not compatible with one of the other modules. Inevitably, problems will arise. I had almost finished building my site,  when it crashed big time. At that point I decided to install it again from scratch making sure to document and back up every step of the way, a practice I follow religiously when I work for a client but that I sometime ignore when working on my own site. Big mistake.

Everything was going fine until i installed Community Builder, a great app for building communities with Joomla, and I linked it with Joomlaboard, a light weight forum that is actually quite useful and even powerful if not the prettiest out there.

I tested the site and it worked fine until I went for dinner. At my return, trying to view my profile as a user in the front end gave me this error message:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 184320 bytes) /-/-/-/-/mod_filename.php

The rest of the page was a blank. I did a quick search in the various forum, starting with joomlopolis, the makers of the Community Builder script for Joomla.

There I found several mentions of this problem but no solutions. In fact, the tech guys seemed to be annoyed at us posting about this problem Their not very useful replay was “Google it“.
From there a gathered that the CB scripts exceeds PHP assigned memory allocation on a given server, and the only cure it seems is to allocate more memory in the php.ini file of the server and restart.
For users on shared servers this is simply not an option. In some cases it may be possible to ask, but more often than not you’ll get a “buy a dedicated server” answer.
What makes this problem very bad is that my site currently is in testing and only my cat, Scruffy, and I know it’s operational. If it runs out of memory with one user, can you imagine what it will do with (Gasp!) 10 or 20 users concurrently?
Eventually I searched the Joomla forum and found out a bit more, but it was while searching Google for “Fatal error: Allowed memory size of 8388608 “ that I hit pay dirt.

I found a post that suggested increasing the memory allocation in the server to 12 MB in the .htaccess file with this script:

memory_limit = 12M

When I tried it my server crashed miserably, but eventually I came across a post on the Drupal forum where they suggested to either do the same thing with the .htaccess file or to place this line

ini_set(‘memory_limit’, ‘12M’);

in Drupal’s sites/default/settings.php file (here is the link to the post )
Armed with that info, I decided to try something crazy and I inserted the same line of code in configuration.php file of my Joomla installation. What did I have to lose?
I was expecting some sort of server error again, but instead I reloaded the page in my browser and clicked on the “profile” page link that was giving me the error

Allowed memory size of 8388608 bytes exhausted

and it worked like a charm. Pure magic!
Just to make sure I wasn’t hallucinating, I commented out the line and tried again : the error appeared again, so my fix was working fine.

However, I was about to encounter another problem. Joomla rewrites the configuration.php file each time it is accessed from the Cpanel. That means that my little, miraculous line of code was getting erased on a regular basis.

Fortunately, in the same post there was another small hack: entering this line

memory_limit = 32M

in the php.ini file in the root folder of the Joomla installation. When I tried that the first time, like the .htaccess file it did not work. However, just in case I could have made a mistake, I tried again. This time it worked and what’s more it’s sticking.
Apparently, this error is quite frequent and I am surprised that, at least in the Joomla arena, I seem to be the only person to come up with a workable solution. This problem, according to the Joomla forums has gone unsolved for quite some time.

Below is the post I contributed to in the Joomla forum, in case you’d like to learn more about this bug.
I hope this article will help others find a quick solution to their Joomla memory error problems, but be warned: not all shared hosting servers administrator will be happy with you if you start messing up with their memory allocation.
I do have a feeling that his little fix my even have the result of speeding up your Joomla installation a bit. after all, it increases the memory allocation for every script, not just the CB Login ones.
Always make sure to back up any file you change or you are asking for trouble.
Original Joomla forum post:
About Memory_limit and fatal errors

Good Luck and thank you again for reading this blog

Marco is a Sacramento based web designer/developer.
Marco’s company is conticreative.com a full service
web agency specializing
in e-commerce and Content management system development, photography, web
marketing and copy writing.

Categories: Blogroll · Troubleshooting Joomla · joomla · open source · web design

Zen Cart and the art of Image Handling

October 25, 2006 · 7 Comments

Welcome to my first Zen Cart article. In this post I’ll try to explain how to manage images in Zen cart and a few tricks I have learned along the way.

By default, Zen Cart displays images in 3 sizes: small thumbnails for the product listing pages, medium for the Product Info page and large, used when the user clicks on the “View Image” link in the product description.

When the user uploads a picture to Zen Cart in the administration interface Zen Cart processes that image when a given page is displayed (Scaling it to the appropriate size for the differnt views).

The problem here is that, out of the box, Zen Cart does not calculates new sizes for the pictures. If the user uploads, for instance, a 400px wide picture, Zen Cart will display it at a smaller size by using the dimensions attribute of the HTML code. In other words, the program will still upload and display a 400px wide picture but at a smaller size. The problem here is that a 400px wide picture displayed at 100px will still take the same amount of time to download and display as the larger image, making the page slower to load. In the list of product or any page where there are more than a couple of pictures this can considerably slow the speed of the page.

The solution is to upload 3 different images for each size. Zen Cart is designed to recognize pictures in its folders that have an extension attached to it to identify their size.
Let’s say that your image name is “productpic.jpg”. We will need to process this image in 3 different sizes.
In Photoshop take the large image generated by your digital camera (NOTE: always take your pictures at the highest resolution possible: it’s easier to take pixels away than to create new ones) and create a small thumbnail with either the width or the height that you had chosen in the Zen Cart image handling dialog, for this purpose we’ll say 100px wide .
(to set the thumbnail size go to: admin site > Configuration [drop down menu] > Images [third from the top] > Small Image Width or Small Image Height) Upload that thumbnail to Zen Cart as you normally would:
Admin > catalog > categories/products > category > product and now your product has a high quality, small thumbnail that will load very fast in list view. With Photoshop or many other (and cheaper) graphic programs you can even batch process your images to create thumbnails in a much faster fashion. I’ll publish a future tutorial on this topic.

For your medium and large pictures, whose size you can set in the Administration dialogs, you can repeat the same process, but instead of uploading the pictures using the Zen Cart administration interface you simply FTP them to their directories making sure to add an extension at the end that will tell Zen Cart that the pictures belong to a certain product but they are a different size. Zen Cart will know to display them in the appropriate pages.

This is how it works:

We have uploaded a thumbnail called “productpic.jpg” at a 100px size.
Now, go back to Photoshop and take the original picture (high res) again. This time make its size 300px (or the size of your medium picture, set at to use as a medium picture always make sure the size is correctly set up in the admin panel).
To set the medium picturesize: admin site > Configuration > Images > Product Info – Image Width (or image height)
Once the new picture is ready, keep the filename the same but add at the end _MED, like this: “productpic_MED.jpg” and upload it to the same folder where the original thumbnail is.

When Zen Cart sees that the picture exist in the directory it will display it instead of taking the thumbnail and resize it to 300px wide. This will create a much better picture without overtaxing your user’s loading times since it will be displayed only when they request to see that product page. Remember that while sizing down a large picture usually will result in very good quality, the reverse is never true.

Do the same for the large pictures. The filename will change to “productpic_LRG.jpg”
Zen Cart will even allow you to define your own _MED and _LRG extensions in the admin interface. I often use just _m and _l and it works just as well.

There are other tricks you should know as well. For instance, it will be unlikely you’ll have all your pictures in a landscape or portrait mode. That means that some pictures will be taller than wider and vice versa. Zen Cart really doesn’t care about that, but your image processing software does. One solution is to crop all your images square, but a better and less labor intensive solution is to separate the portrait and landscape pictures in different folders and to create 2 different batch scripts, one for each. Photoshop CS2 even has a scripting utility (beside the “Actions” palette) that should be able to handle that as well (I have yet to try it), and there are plenty of PHP scripts that handle the process quite well.
Again, I’ll be happy to publish a step by step tutorial in a future article.

Installing a better image handling system

The solution I like best involves installing a Zen Cart contribution called Image Handler 2.0. While its installation it’s not very complicated it’s not for the fainthearted. You should at least have a vague idea of how to use FTP, PHP and the Zen Cart file system. However, once installed it allows you to upload a single large image and have all three sizes created on the fly as needed. No messing around with Photoshop or with multiple uploads. One other great feature is the ability to apply a “watermark” with your logo and a copyright notice on every image. The only drawback I can see is that apparently it creates the images “as needed”, meaning rignt before they are displayed. While this is faster than downloading large images as thumnails, it does put a load on your server.
I use Image Handler2 myself and I am very impressed with it. I am even thinking of creating a template installation for Zen Cart that already has the image handler installed. I’ll keep you posted

I hope this article gave you some idea of the possibilities. For more detail there is a very nice article called Image Management for Dummies (I really dislike that name) that goes in more detail. It’s available here.
For more articles like this, please check out my site at conticreative.com
Thank you for reading so far and feel free to let me know how I can improve this article.

Categories: open source · web design · zen cart

Conticreative – introduction

October 24, 2006 · 1 Comment

Welcome to Conticreative.com first “WordPress” blog.

I hope in the future months to publish a number of useful articles on web design, open source (in particolar Joomla CMS, Zen Cart, OScommerce, Drupal, etc.) , web marketing, SEO and more.

I am a web designer based in Sacramento and my company is called (surprise!) Conticreative.com
We specialize in integrating Open Source e-commerce and CMS (Content Management Systems) for all kind of businesses, but currently our market is mostly comprised of fairly new entries in the web publishing business (Yes, I am serious. There are plenty of people still debating whether having a website is something they should consider) and a number of redesigns from companies that tried the outsourcing route and were less then thrilled with it.

I worked in a variety of web based business, mostly as a designer/developer, since 1994, when dinosaurs roamed the web. After many years working for others and having to suffer their stupid decisions (sorry Bill) I have decided to make my own stupid decisions with the help of a few trusted friends.

So far I have been lucky and my little business is taking shape very nicely.
One decision that I don’t believe I am going to regret for the foreseeable future was to shift my development focus from custom, “build’em from the ground up”, websites to the incredibly good offerings available in Open Source (I will explain what that means in an upcoming post in the meantime look here).
Using Joomla or its e-commerce cousin Zen Cart (itself a derivative of OScommerce) I have been able to build a fantastic array of capable and for the most part accessible websites for my clients and I have become a true evangelist for everything Open Source.

When I was a corporate slut, we had scores of designers and developers each building a small part of a website. therefore for many years I was able to see only a small part of the picture during production. My eventual career rise gave me the opportunity to manage the whole process, but I was still limited in what I could do on my own.

When I decided to go “solo” I had a dilemma: I certainly knew how to build websites, as I was able to write each piece of the puzzle on my own, from pure design to coding. However, I had to keep my client’s budgets in mind and most of them could not afford the month of wages I had to charge them to justify my effort. I had to find a better solution that didn’t involve hiring a bunch of employees and that would still deliver a product up to my standards.

Since I worked mainly with Java based application development, I took some classes in PHP and MySql. Learning PHP exposed me to the world of Open Source e-commerce and CMS applications.

I quickly started testing the applications on my own server and I found them often better written and more powerful than many projects we used to develop with java. I guess one of the reasons is that PHP applications are often created by large teams of developers with the prompt feedback of yet more users, allowing the applications to mature very rapidly and reach a level of features and sophistication that in a traditional business enviroment would be impractical and cost prohibitive.

Eventually I build my first Joomla based application, just in time for Joomla to separate from the Mambo development team (long story).
Beside the first few days of terror when I realized that Joomla’s Section – Category system was a bit more complicated than I bargained for, I was truly very impressed. More importantly, my client was even more impressed than I was, especially at the price and the features I was able to deliver using Joomla. For less than the price he was quoted for a “brochure” website I built him a user forum, an e-shop and a blogging system in less than a week.

Fast forward to the present, and after finally finding some time to work on my own Joomla site for Conticreative.com I also decided to start publishing a blog of tips and tricks I learned or discovered by using Joomla and Zen cart. One of the downsides of Open Source software is that often the documentation is atrocious and I figured than instead of bitching about it I could convert the effort I make in understanding and implementing the many features of the applications into useful tutorials.

While I was at it, I figured I could also use the forum to voice my opinions and try to initiate dialogs with fellow developers, potential clients and anyone interested in the business of open source, web development and web design (and marketing, and photography, and the war in Iraq, and let me stop here).

So, welcome to my new blog and don’t be afraid to tell me I am full of crap. I am used to it.
After all I have been married over 20 years (and I love my wife very much).
Most of all, I hope you’ll find the articles useful and entertaining as well as informative.

Good luck
Marco

Marco is a Sacramento based web designer/developer.
Marco’s company is conticreative.com a full service web agency specializing in e-commerce and Content management system developement, photography, web marketing and copy writing.

Categories: joomla · open source · web design · zen cart