This seems to have been the week of weird caching issues.  I was working on a Drupal project and learned I had to flush the caches when creating templates.   Of course, that was after a few hours of banging my head against the desk.

Then, I was working on a static website and having trouble reloading the css changes.  The site was located on a client server, not one of my own.  I updated the stylesheets and tested on my local machine.  Everything looked fine.  And then, after uploading to the client server, the changes would not take place.  I would clear the browser cache and reload the page.  Still nothing.  So, I tried several different browsers and even a computer that had never loaded the website.  Still nothing.

I sat there scratching my head as my eyes started to pop out of their sockets.  Another caching issue.  You have to be kidding me.  I knew something was caching the stylesheets.  But what?  With a few Google searches and the proper keywords, I came across Jason Beaird’s website, Jasongraphix.  Jason is the author of Principles of Beautiful Web Design,  a great read.  He has a post on his site called CSS CacheBuster which describes a solution to the issue at hand.

The server is caching the stylesheet.  You need to make the server think the stylesheet is a dynamic page, therefore changing constantly.  This keeps the server from caching the stylesheet.  By adding a query string to the stylesheet, you have successfully tricked the server.

<link href=”stylesheet.css?cachebuster” type=”text/css” />

Problem solved.  Though, you should still try to solve the issue on the server.  In my case, I was unable to access the server and therefore this solution worked beautifully.  There is still a chance that the server will cache this page sooner or later.  The address stays the same.  You could change ?cachebuster to ?cachebuster1, ?cachebuster2… and so on.  But that gets to a pain.  I just added a random number to help eliminate the issue.  My final code looked like the following:

<link href=”stylesheet.css?cachebuster<?php echo rand(0, 100000);?>” type=”text/css” />

If you are unable to modify the server settings, use the method above.  Otherwise, I would suggest checking your server settings and turning off the stylesheet caching.

Phoca Gallery is a photo gallery component by Phoca for Joomla!.  This component is highly extensible but lacks one basic feature.  The ability to edit the copyright information.  In the earlier versions, the copyright was easy to find, wrap a tag around and style.  With the newest version, the copyright has been moved and buried in the code.  I would speculate this is due to many users removing the copyright information.  You should always leave the copyright information if the author asks.  The product is free.  By removing copyrights the author may start charging fees for use.  But you should be able to modify the styles of the copyrights.

I searched several forums, blogs, etc and found nothing on where the copyrights were stored.  It took me a little bit of testing to finally determine the location.  I only use the categories and category views.  Therefore, this solution may only apply to them.

In order to edit the information, go to line 1589 in the file /components/com_phocagallery/views/category/view.html.php.  Around this line you will see something similar to the following:

parent::display($tpl);

echo $tmpl['go'];

The line echo $tmpl['go']; prints the copyright information.  The copyright is not wrapped in a tag with a class.  Whenever the category rendered, the footer was the same size as the rest of the content.  You should keep the copyright information present, however, you should be able to style it so there is little effect to your page content.  So I modified the code to look like the following:

parent::display($tpl);
echo ‘<div class=”phoca-footer”>’ . $tmpl['go'] . ‘</div>’;

Hoo Haa….  We now have a CSS abled Phoca Gallery footer.  As I said before, please leave the copyrights in place.  The author worked hard on the component and is providing it for free.

HTML should always be used for structuring your content.  You should try to avoid using it as a means of design.  Cascading Stylesheets (CSS) are for design, not HTML.  Listed are a few of the CSS oversights I see on a common basis.

Inline Styles

Most of the third party components I use contain inline styles.  This is where the stylesheet attributes are coded directly into the HTML tags.  This makes layouts harder to change as you have to touch all of the style attributes rather than editing one file.  It also adds more markup to your HTML file.  More markup means search engines have more code to digest than content, which can potentially hurt your ranking.  I end up going through the third party components and creating my own design friendly views.  This can be a pain, but someone has to do it.  So, when developing a web program for others, try to use standards and focus on content not design.  Your system will be much more portable and beneficial to it’s users.

The Overflow Problem

The overflow problem occurs when you are floating items.  Normally, in a column based layout you will wrap the columns in a div tag or some other tag that suits your needs.  The main div will contain a background color or image.  As the columns automatically populate, they overflow the main div.  This means if there is a height on the main div, the columns flow outside and the div does not automatically resize.  Some people will use the following code to solve this problem.

<br style=”clear”/>

This is perfectly valid. However, it integrates the content structure with the design.  This may cause issues when trying to apply a new, css based layout.  It also adds extra markup, which bloats your code.  The better way to solve the overflow problem is to apply the following style to the div wrapper:

overflow: hidden

This tells the wrapper to automatically flow with the floated elements.  Therefore, solving the problem without any extra HTML markup.  Wooo!

Browser Compatibility

It is extremely difficult to get most designs to render properly on all browsers.  Your main stylesheet will render on most browsers other than Internet Explorer (IE).  Many designers include one stylesheet for all browsers.  They either do not test in IE or the site worked in IE and they did not test other, more standards compliant browsers.  In almost every design project I have worked on, I have had to include IE only stylesheets.  This can be done with conditional comments.

<!–[if IE 7]> <link href=”ie7only.css” rel=”stylesheet” type=”text/css”> <![endif]–>

<!–[if gte IE 6]> <link href=”ieonly.css” rel=”stylesheet” type=”text/css”> <![endif]–>

Conditional comments are ready by IE.  Above, the first checks for IE version 7 and if it is present then the ie7only.css file is used.  The second checks for anything greater than IE version 6 and then renders the appropriate stylesheet.

You could then use a normal stylesheet for most major browsers and add modifications to that stylesheet in an IE only file.  Then, pull the IE file when necessary.

Conclusion

These were just some things I ran into this week between third party websites and client redesigns.  Hopefully, a designer or developer out there finds this useful.

I was recently working on some file upload programs.  I found a few file uploaders that could easily be integrated.  Though, none were very user friendly.  What I wanted was a very easy, point and click uploader.  One similar to the basic form file upload where you click the browse button and search the computer.  Every file uploader I looked into was much more advanced.  They would give users a broad range of file upload and edit capabilities.  In my experience, the more easy to use a program is, the more your customers will appreciate it.  Finally, I ran into a solution that worked.  In A Flash Uploader by Verner Studio was the perfect solution.  It is a small Flash generated file uploader which runs on PHP.  The script is highly customizable.  Though, as with most free versions, it does display the In A Flash logo.  I was able to install and configure the uploader within minutes.  The really nice feature, is that you can tell it what script to process after the upload.  So, I went ahead and created several different scripts to handle different upload types – music, images, etc.  This way my systems could properly modify the files and organize them.  If you are looking for an easy to use uploader, then I highly recommend In A Flash.  It will give you a easy to use interface, plus some of the following benefits:

• Progress bar – See the progress of the file as it uploads.
• Ability to limit file uploads to specified file extensions.
• Ability to customize text and colors
• Ability to customize the call back script
• Easy debugging capabilities
• Did I mention it was easy to install and, most importantly,  use?

I have only run into one small bug.  When uploading large files – 5MB or more – the upload progress bar does not show up.  It shows the uploading text, so you know it is in progress, however you do not get the percentages.  This may be a configuration issue on my end, but I am not sure yet.

If you are looking for a file uploader, be sure to check out In A Flash.

Secure Sockets Layer (SSL) is the magic that encrypts your data between a clients computer and your website.  This way no pirate types can pull it out of the ether and use it for malicious purposes.  I was working on a project a few days ago and ran into some issues with SSL.   After struggling with the hosting provider, we finally finished the certificate install.  It took a while because one of their automated systems botched the transfer process.  Then, a technician had to manually install the certificate.  It is odd. I am a programmer who much prefers manual processes rather than automated processes anyway.  But that is for another entry.  Anyways, the SSL was installed but did not appear to be working.  Hmmmm…

I looked into the issue and realized that the site was using iframes.  Uh-oh.  First of all, iframes are horrid.  Honestly, try integrating by parsing xml or some other file if you can.  Unfortunately, the third party website being used only allows for iframe integration of this module.  There are other ways to do it but they were even worse.  So, I figured out the issue was with the iframes.  What I did not understand was that I could not find a blog entry that properly discussed a solution.  All anyone said was “you can’t do it, so don’t” or provided solutions that did not work.  But ah-ha.  I found a solution that works fairly well.  It is a work around, but it works.  The site is primarily an informational site with a small store front.  Therefore, you can limit the pages where the iframe appears to the informational pages and remove it from the store front.  Then when someone is using the store front, you force the page to display via SSL.   The code solution follows.

//First I made sure to check and see if the page was the one that needed SSL.
//If SSL was not turned on I redirected to the SSL page
//Of course, you would have your own unique way of determining the page.
//Joomla! uses the $option variable while other CMS's use different identifiers
if ($page == 'needs-ssl' && $_SERVER["HTTPS"] != "on") {
$newurl = "https://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"];
header("Location: $newurl");
exit();


//Run through this if the page does not need SSL but SSL is on.
//This helps eliminate some wierd things that happen when the SSL was on and iframes were used
//You could probably leave the SSL on. But like I said, sometimes wierd things would happen.
}elseif($page != 'needs-ssl' && $_SERVER["HTTPS"] == "on"){
$newurl = "http://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"];
header("Location: $newurl");
exit();
}


Then I just checked to make sure the page was not the store front when displaying the iframe. Problem solved.

By the way, the solutions that claim to work by installing the blank.html file and using javascript to reset the iframe do not work.  It still causes issues with the SSL because iframes are not secure.  You can pull information from another site via some scripting language, process it till your fingers turn blue, and then create the output.  But pulling information actively through a third party website is seen as a security risk and rightfully so – yet another topic for another day.

I was working on a project today and needed to pull module parameters into a script I was creating.  After doing a lot of searching online for blog and forum posts I was unable to find a solution.  Then I scavenged through the Joomla! documentation on information for the module classes, hoping to stumble upon a solution.  I was relieved when I decided to do another Google search and stumbled upon 2 solutions that I merged to help meet my needs.  Hopefully, this will help someone else out there.

This is what I did to get my script to pull parameters for a specific module position.


//Import the module helper
jimport( 'joomla.application.module.helper' );


//Pull the module position you are looking for

//I believe JModuleHelper::getModule('module-name') also works for a single module

//Of course replace module-name with the position of your modules

$module = JModuleHelper::getModules( 'module-name' );


//Initialize the output var
$moduleOutput = "";


//Cycle through each published module
foreach($module as $thisModule){


//Make sure it prints xhtml
$attribs['style'] = 'xhtml';


//Render the output
$moduleOutput .= JModuleHelper::renderModule($thisModule,$attribs);


}
//Print the output
print $moduleOutput;