Footers are often an overlooked aspect of designing a site - when they can actually be kinda handy and informative. In this tutorial we'll go through some options you can have for your WordPress site.
They take different bits of information - archived posts, the "about" message and some links - and arrange them in a sidebar sort of format. This is then styled to work more like a footer, moving it down to the bottom of the page and laid out horizontally. The complete code for the tutorial can be dropped easily into the wp-content folder (named "WPFooter").
Jonathan Snookhands off a handy tip for the CakePHP developers out there concerning the debugging information that can be displayed at the bottom of your application's pages.
I just wanted to document this somewhere but whenever I work on a CakePHP project, there's always the debug info that sits at the bottom of the page. It's big and bulky and once I'm off the default CakePHP styles, it's usually pretty ugly. I've done various stylings but I finally took a moment to implement a really simple idea: Fixed position the table and then use hover styles to toggle the visibility.
He includes the simple four style entries that can be used to tame this debugging information down into something a bit more useful (and less intrusive).
In a new blog post, Paul Jones looks at three aspects of coding style - line length, volume and density - and how different people have different assumptions as to what's "right".
When it comes to coding style, there are are various ideas about how you should write the individual lines of code. The usual argument is about "how long should a line of code be"? There's more to it than that, though. Developers should also take into account line volume ("number of lines") and line density ("instructions per line").
He mentions the PEAR style guide when talking about line length, reading code like and sentence in line volume/density and how the "shorter is better" concept can be pushed to its extreme limits taking code into the unreadable zone.
In the second part of their look at the Stage design pattern today, DevShed moves up from the previous article to implement a more "real world" example of the Stage pattern in action.
Essentially, what I plan to demonstrate here is how this pattern can be used to build different versions of a given web document on the fly, either for display on a typical computer monitor, or for printing.
This involves the creation of a class to define the styles for both sides - print and screen - and a class that will figure out which of these needs to be applied.
The 'true hacker!' blog has a new post today that gives you a quick four step process for creating some clean, Digg-style URLs for your site with some simple Apache configuration changes (mod_rewrite).
You might have noticed that Digg has a cool way of maintaining clean URLs. Digg actually uses LAMP - Linux/Apache/MySQL/PHP. But where are the .php extensions? The answer is here. 4 steps to implement your own Digg style clean URLs.
His method turns on Apache's rewrite engine (you do have mod_rewrite enabled, don't you?) and adds a rule to push all of the requests to two default PHP files. There's also a ForceType method that can be used to achieve the same effect. One .htaccess file later, you're in business and the PHP script only needs to access the $_SERVER['REQUEST_URI'] value to get the parameters.
At the 456 Berea St blog today, there's a popular new post that demonstrates a simple (yet effective) method for switching out the style sheets on your site at the whim of the user.
Want to have a style switcher that lets your site's visitors choose a different style sheet? Want it to work even if there is no JavaScript support? The trick is to use a server-side language like PHP, which is what I use for my style switcher.
Using PHP to let the user switch to a different CSS file is nothing new. But it is one of the things that I am often asked about, so I thought it would be good to have a write-up to refer people to in the future.
The code for the switcher is only about five lines long, implementation and all, but it's a nice, clean way to do it. It would break if the viewer didn't have cookies allowed on their system, though.
In a new post on his blog today, Paul Jones mentions a framework that might bridge the gap for ASP developers making the move over to PHP, Prado, and some of the issues that more traditional PHP developers might see around it.
An old buddy of mine wants to start using PHP, but the problem is that he's been working with Microsoft technologies for so long, he doesn't get "the PHP way". His background, for many years, has been with ASP.NET, COM, and those sorts of things.
As it turns out, there's a PHP framework out there that maps well to "the ASP.NET way": Prado.
He talks about how the framework is structured and what non-PHPers might find to like about it, but he also wonders if the phrase "the PHP way" might be better replaced by a more definitive term to describe the way most PHP develoers prefer their apps to work.
In this post from the Zend Developer Network, there's some talk about a web service that can be useful to any PHP developer out there - new to the language or not. Bad coding practices can lead to hard to read code, the worst of them is not formating your code correctly. Thankfully, there's PHPFormatter to help out.
Using this service, you can upload your code, beautiful or crappy and it will format it for you. If you don't bother to register, you can choose from several of the standard formats like PEAR, BSD or GNU style formatting. If you register with the site (free) you can define your own style.
Cal also includes some of the reasons the PHPFormatter crew give for making code beautiful, including bringing a project's code up to your current style or fixing a downloaded, unreadable script. You can also use it to format your code to fit with the PEAR style.
For those of you that have been following along, PHPBuilder.com has posted the third and final part of their "Using XML: A PHP Developer's Primer" series. Even if you haven't been keeping up, it's worth a look.
In this edition, they look at more advanced topics - a deeper look at Ajax and how to style the data you get back with XSL, both on the client and sever.
To start, they look at XSL - what it is, how it's used, and some code examples of both the XML and XSL structures to style XML data into a valid HTML page. Of course, you'll need the PHP extension to get this all working, so they step you through the installation/enabling of that as well.
They touch on other topics (like passing variables to a stylehseet and XSLT in Javascript) before getting to a simple XSLT and Ajax example - pulling book data and formating it with examples of both the PHP and Javascript sides.
Richard Davey has posted this new item today to share a helpful tool for debugging your PHP scripts without having to purchase an expensive debugger package - dBug.
When it comes to debugging PHP applications most developers fall into one of two camps. They either use a package such as Zend Debugger, set breakpoints and painstakingly go through their code checking the variable values. Or alternatively for those of you not using $200 worth of IDE, and a common method employed by more php 'beginners', they will print_r() and var_dump() all over the place to check what is going on, the resulting dumps appearing inline with the rest of the site.
Personally, I use both methods, and I imagine most other developers are in the same boat. When you need a quick variable output or to see the full contents of an array you often can't beat var_dump for speed of implementation. Which is why this superb little class file that was recently bought to my attention (thanks Chris!) should be of interest to you all.
He gives some visual examples of how the output from this powerful little script works, including the simple three-line code to make it happen. The library really shines when it comes time it echo out more complex data, creating easy to read tables of information versus the normal difficult to read var_dump/print_r output.
