I’ve been remiss in calling attention to the redesign launched here a few months ago. May thanks to Stephanie for helping with the design.
There’s still a fair amount of tweaking to be done (isn’t there always?), and I can’t promise universal browser support.
I’m experimenting with a few newer CSS features. Notably:
- Headers use the Republikaps font, loaded using
@font-face
- A fair number of drop-shadows are scattered throughout
- The border of the main content area is a combination of two rounded-corner boxes, the inner with a drop-shadow, the outer with an inset drop-shadow (note that due to a bug in WebKit, Safari and Chrome users may see a square outer border)
Much of the above won’t be visible to the 6% of my readers still on Internet Explorer. Frankly, I’m alright with that. In the past month, Opera’s 1.69% among visits to this site outranks IE6 and IE7 combined.
Let me know what you think, or call my attention to any bugs you might notice.
There’s one primary distinction between Drupal and WordPress. In Drupal, URLs map to PHP functions. In WordPress, URLs map to documents (or, quite often, collections of documents). The former can certainly be powerful and easy to work with. The latter, once you get used to the paradigm, can provide an incredible simplicity, powerful in its own way.
I was building a website today that has a location-based search component. Basically, I have a collection of posts with addresses, and I need to be able to search for addresses within a given distance of a queried address, and sort them by said distance. To be honest, that’s hard to do with WordPress. But it is possible…
Continue reading →
Building on my previous post about creating archive pages for custom post types, there’s another piece to add to the puzzle.
You archives pages will use the default index.php template. If you want to use a different template, you’ll need to hook into the template_redirect action to specify your template file. I like to use a file name like type-MY_POST_TYPE.php (although that’s easily changed), using the function below.
Continue reading →
When you create a new post type in WordPress using register_post_type(), WordPress does not automatically create a page for listing the archives of that post type. It’s possible to create one, though, without too much hassle.
For example, you can create an post type called article, and set the permalink for that post type to articles (i.e., an article will have a URL like http://example.com/articles/my-article-title).
Where do you go for a list of all articles, though? You might assume http://example.com/articles/, but you would be assuming erroneously. You could create a page with the slug articles and use a custom template for that page, but that doesn’t work with paging (e.g., http://example.com/articles/page/2/).
Instead, you need to fiddle with WordPress’s rewrite rules. (And thanks to Andrew Wilson for helping me understand this.)
Continue reading →
I’ve recently begun digging into CodeIgniter for a new project I’m working on. One of the first things that strikes me is the lack of a good way to set up your database tables. The standard method seems to be, in a nutshell: point and click in PHPMyAdmin or import a SQL file from the command line.
So, step 1: create an Install controller. This is a pretty basic controller that you access at http://example.com/install (and which you’ll disable after developing the site). All it does is create the database tables you’ll need and add any initial values you might want. You can figure the rest of it out on your own.
But I have a problem. I want to auto-load the session library for all of my controllers. That’s easy enough: just add $autoload['libraries'][] = 'session'; to your autoload.php file. The session library, though, requires a properly-defined table to exist in the database before it can be used.* If you auto-load it, though, it will also auto-load for the Install controller, which won’t work, since the tables haven’t been installed, yet.
*Technically, it can work without a database, but then I’d have to keep changing a configuration setting every time I want to re-install the database, which I’m doing rather frequently in the early stages of building this app.
So, I made a hack to get around that. Please note that I do not recommend this on a production site. This is for development purposes only.
Continue reading →
