Posts Tagged ‘php’
WordPress finds new ways to amaze me; some of these things are neither impressive nor particularly noteworthy, except that these things enable users to customize this platform in ways unimaginable to regular Joe Blogger, who simply uses the system. And in spite of how common such things are to those who truly dive into it, I struggled for quite a while trying to find the best way to change a bit of core functionality.
If you scroll down to the bottom of the site on the home page, and on any entry page, you’ll notice a set of buttons that will help you navigate to the next and previous entries, or the next and previous pages of the home page. I needed a way to style these, and oddly enough WordPress did not provide a class name for either of those links. Too bad. So I needed to find out how to adjust that in order to target those links. In addition to that, I needed to also make a small change that classes wouldn’t have allowed for, which was to get the function to output code for the cases in which there were no other pages or posts in a given direction. My first thought was to find whatever core file these functions were located in and then make the change there; I proceeded to do this, got it working, and decided that I should go about this in a different way if I ever wanted to upgrade without having to change that file every time–if I even remembered in those instances.
The tags in question were: next_posts_link, previous_posts_link, next_post_link, and previous_post_link, as well as a few more functions that were related to them. Each of these provides the basic functionality I needed to modify; I tried to replicate these functions, using the same name, in an effort to essentially overwrite the original WordPress core functions. Well, I located them in the link-template.php file, copied and pasted them into my themes functions.php file, and proceeded to make the necessary changes. When I uploaded functions.php and refreshed my site, I had a big giant error; actually it was less an error and more a blank screen, which is worse in a lot of ways as you have no idea what went wrong. I should have known from my programming experience that I couldn’t duplicate these functions in this way.
I was stumped for the longest time, and search after search on Google was leading me towards something called, add_filter, which it turns out doesn’t quite overwrite the function so much as filter the function results through your new function; this was not what I wanted to do on any level. I couldn’t manipulate the data through a filter to achieve the needed results.
After some time, and a lot of searching, I landed on a WordPress MU forum (still not sure what MU is), that gave me my answer–the most obvious answer–which was to take the functions I needed and rename them. I could then use those new function names in place of the old ones wherever I needed them in my theme files.
That’s easy, ain’t it? Why don’t people explain this more often, or even need to to do this enough for it to be found on Google?
Update 1/19/2010: I wanted to clarify just in case some one stumbled upon this looking for an actual bit of code that might show them what I was up to. So here goes.
Instead of adding a filter to the function you want to change:
add_filter('next_posts_link', 'new_next_posts_link', 0);Add a new function to functions.php and call it in your template wherever you were going to use the old one.
function new_get_next_posts_link( $label = 'Next Page »', $max_page = 0 ) {
global $paged, $wp_query;
if ( !$max_page ) {
$max_page = $wp_query->max_num_pages;
}
if ( !$paged )
$paged = 1;
$nextpage = intval($paged) + 1;
if ( !is_single() ) {
if( empty($paged) || $nextpage <= $max_page) {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<a href="' . next_posts( $max_page, false ) . "\" class=\"next\" $attr>". preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
} else {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<span '.$attr.'>'. preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</span>';
}
}
}
function new_next_posts_link( $label = 'Next Page »', $max_page = 0 ) {
echo new_get_next_posts_link( $label, $max_page );
}I’ve essentially adjusted this line:
if ( !is_single() && ( empty($paged) || $nextpage <= $max_page) ) {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<a href="' . next_posts( $max_page, false ) . "\" $attr>". preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
}And changed it to this next bit in order to add a class to the link for styling purposes as well as to display a grayed out link if there was no next (or previous in the case of those set of functions) page.
if ( !is_single() ) {
if( empty($paged) || $nextpage <= $max_page) {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<a href="' . next_posts( $max_page, false ) . "\" class=\"next\" $attr>". preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
} else {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<span '.$attr.'>'. preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</span>';
}
}So, again. If you’ve got something to modify, do it this way. The functions.php template file is your best friend.
I’ve been working on a bit of a personal project lately and decided the easiest and best way to introduce a blog would be to install WordPress, plus I really wanted to give that system a little more of a try than I had in the past.
My gut reaction upon installing and settling on a theme for modification was that this was REALLY easy to work with and highly customizable. I had, in fact, gotten used to working with my own MovableType installation, its quirks, and its own templating system, but the php based WordPress on my server was a breeze to deal with compared to the former. It was faster, offered better plugins, easier templating, and I could even edit the hell out of those plugins to customize the installation even further for my needs.
I’m so convinced by my experience that WordPress is the superior publishing platform for anyone looking to get started beyond the free services and put up a site on their own domain, that I am absolutely going to develop the next iteration of this site with WordPress in mind.
MovableType has been good to me, and it truly is a very powerful platform, but my servers don’t deal with it, and it is SLOW as a result. Plus, all of the plugins I want to use aren’t offered for MT or don’t offer what I need. And that can be frustrating.
What I like about MT, though, is the publishing experience. I feel like I can easily add tags to any entry with little problem, and the interface (MT 4.0+ at least) is minimal and easy to use. Previous versions were a bear to work with, I’m afraid, but 4.0+ is quite fantastic.
Anyway, my conclusion: WordPress for the future iteration, but MT will suffice for now; WordPress is superior to MT for beginners and its ease of use; and MT is not likely to catch up.
Update: 5/15/09 I am currently in the process of converting to WordPress. Manually. Really frustrating, but worthwhile. I’ve also discovered that it is a superior publishing experience.
I’ve never been much of a programmer; and I’m probably unusually intimidated by JavaScript. I can’t explain its effect on me, considering what I’ve tackled with php (which, I suppose is arguably pretty simple and inefficient stuff), but it’s not something I’m proud of.
At any rate, this week I decided to tackle a bit of a problem that has been bothering me for as long as I’ve had the current design on my portfolio site.
The portfolio side of things exists as a single page site with work samples, a little information, and a contact form. The contact form would require that you reload the page upon submission in order to process and send the message, which always seemed like a jarring experience from a user interaction perspective.
In order to solve that problem, my solution was the ever popular: AJAX.
I’ve used some jQuery plugins in the past, so I was familiar with the framework; after doing some reading and thinking about compatibility with my current setup, I decided that jQuery’s built in AJAX implementation, and animation effects, would be just about perfect for my needs. Why? Because the jQuery framework is incredibly useful to me, as a designer, with little time for figuring out how to implement all of these fancy user interactions with JavaScript. Plus, it’s the framework I use for everything.
As of recently, I’ve had a particular layout for my gallery section that just wasn’t working for me. Well, it was probably OK, and I generally approved of it–since I designed it at some point–but I always thought it felt awkward.
I’ve had the thought running through my head for a few weeks now that it would probably be a good idea to adjust the layout; perhaps to spice it up, or make it a little more pleasing to my eye. Maybe this is perfectionism kicking in, but I really enjoy making these adjustments and experimenting in how I go about completing them.
What I initially decided to do was adjust the teaser image size by widening all of them to fill the entire 9 column width–which is the size of my primary content section (I have designed this site based on a 24 column, 936px wide grid). Because of that adjustment, I have had to change the way I display each project’s summary information. There are still many adjustments to be made, but so far so good.
What I’m most proud of in all of this change, however, has nothing to do with what is ultimately displayed. No, what is most impressive lies underneath it all. That’s right, I’ve gone and done something completely unnecessary–albeit, very cool–in the gallery display options I currently possess.
I initially didn’t want to commit to the larger size, so I created a bunch of backups of my CSS files and various source code files just in case I wanted to switch back, but why the hell was I doing that when I could write a bunch of functions that would do it for me?
On my workpage, in order to display the gallery, I include a file that possesses all of the appropriate php; in this way, if I need to make an adjustment, it’s pretty easy to go through and change whatever code I need. But there was one part in particular that became a bit of a hassle to adjust. Whenever I needed make a quick layout adjustment, I had to wade through three different files to do it–chalk it up to my inexperience I guess.
To alleviate the mess, I took that section and turned it into a function that would produce that section for me; now I could separate it from that file and consolidate everything, putting it all into one central location for quick adjustment action.
In the file that contains my primary functions and controls page numbers and gallery categories, I included the newly created function (small layout size) and created another (large layout size) that I would use based on a couple of different settings variables. I also set it up so my CSS file is created on the fly–that is the one that would determine which CSS files to @import.
Because of this simple little setup, I’m able to switch between those two different layouts in about five seconds, plus any adjustments in the future will be a matter of adjusting a couple of functions.
That’s just easy.
When I set out to work on the current version of my website and portfolio, I initially displayed my work in much the same way as I displayed it in the last version. All of my pieces were in smaller thumbnail versions and each one (about 30 at the time) were displayed on one page; I had pagination ready to rock and roll, but with the format the thumbnails were in and the lack of real information being displayed about every piece, it didn’t make a whole lot of sense to use it.
Moving forward on this design was pretty straightforward, but I stuck with the old way initially because I had built a pretty intricate system to handle my portfolio. Not that it was difficult to adjust, just that it would take me a little time to swap things out.
When it came down to it, though, my final design on the portfolio on this version required something a little more sophisticated than what I had set up. I needed to be able to adjust how everything functioned, and quickly. I also wanted it to be quickly and easily customizable.
A quick run down of what I wanted to do:
- I wanted to be able to use the system I had already built to add, edit, and delete portfolio pieces quickly and easily.
- I wanted to use the information in the database that I had never displayed before but had built into the system.
- I wanted to be able to display all of the pieces by their project type.
- Finally, I wanted to utilize pagination for the overall portfolio, and for each category of project.
All of this could be accomplished, but it was going to require a whole lot more than I was truly prepared for, because I’m not much of a programmer. I knew some things, in php, and I knew how to accomplish those things with some very basic straightforward programming. This time, though, I needed to make some custom functions. This was going to be the only way to make this work. It might not be necessary, or accurate, but I was going to try my hand at OOP (something that isn’t really needed for this application, but something I did anyway).
Prepare, programmers, to be unimpressed.