Creating Tabs on Listing Pages in DirectoryPress Ain’t Easy
Tabs are standard fare in most software. From browser to calendar to finances to video to social media apps . . . Not only have we become used to them, we’re actually grateful for how they let us group more, click less, saving us precious space and time.
- First, The Results
- Now, A Few Things to Watch Out For
- Dealing With The Code and _single.php
Wherever, however we access the apps we use, we’re looking for and reaching towards The Tabs.
And when they are not there, or there aren’t enough of them, we want to know the reason why.
First, The Results
Another Tech Mini-War: Custom Tabs and Custom Fields
Whether hellish or heavenly, I love tech stuff! Whether these moments (hours, days) elicit a few choice words or a resounding whoop of joy, I wouldn’t trade them for anything. VT
Those words are from 5 Tech Escapades, a light-hearted glimpse into some of the challenges encountered over a year ago. My latest technology challenge has been getting the DirectoryPress software to do what they said it would do and otherwise bending it to my will. I’m using it to build a geo-targeted small business directory for my local area. When it comes to battling this pretty beast, I’ve won some and I’ve lost some.
One of the battles I was determined to win was the Tabs War.
The design of the directory allows a small business owner to enter a wide range of pertinent information about their business. But who wants to scroll through a long list of end-to-end details? That’s why we love tabs! The second part of this process involves using custom fields because that’s where all the “extra” information is contained (like Facebook Page, Twitter username). Thus, the challenge was to create new tabs, pull in custom fields data, then display it all nicely in groups on the new tabs.
After some false starts and a few exclamations of “By George, I think I’ve got it!” I stumbled upon a tutorial that made sense, that provided the necessary code, and was written by a responsive individual.
Why doesn’t DirectoryPress make it easier to add custom fields and additional tabs to directory listing pages?
Well, maybe they will in the next major version. In the meantime, thanks to SimonSwiss and his DirectoryPress Custom Tabs tutorial, I now have tabs that show up as part of the Listing page at the coming-real-soon local business directory. Most of you won’t be interested in the rest of the discussion on this page as it is more-or-less a holding place for screenshots and related code that can be shared with anyone else trying to resolve this issue in the WordPress-based DirectoryPress software, but just in case you’re ever struggling with tabs in DirectoryPress, read on.
You’ve Got . . . TABS!
New Tabs Using Custom Fields on Listing Page
The new tabs added are Contact and +. Why the plus sign? Because an actual word was too long and messed up the format! The + stands for Extra!. Here you can see partial contents of the Contact Tab with a group of custom fields.
Getting to this point involved adding PHP Code to the “_single.php” file and adding a couple of plain-English lines to the “language.php” file. SimonSwiss provides the necessary code in his tutorial.
After getting the hang of what went where, I took a little liberty and added some headings. Big stuff!
Now, A Few Things to Watch Out For
Weird things happen when you’re trying to make software perform to your satisfaction. Sometimes you don’t have all the information you need; at other times circumstances beyond your control can bork your process or have you chasing after issues that arise even after you’ve done everything right.
Database Issues Caused By Your Host
Hopefully you won’t encounter this, but do be aware that database issues at the server level can cause you problems. This happened to me after I had the DirectoryPress tabs set up and working. Within the past few weeks, my host upgraded MySQL.
- On this site, it slowly killed CommentLuv Premium plugin and finally brought the site down altogether. (To their credit, Site5 tech support gurus fixed those issues within a few hours.)
- On another site, anything I did within WordPress took hours to be reflected in the database. When my tabs suddenly quit working, I spent time troubleshooting the issue only to discover that slow database updates on Site5 were causing this grief. However, once the updates finished, everything was back in order, including my Packages displaying on the Submission Page
The moral? If there is no apparent reason for your tabs to not be working, check with your host to make sure they’re not the reason for your problems. Or if you are handy with databases, look around a bit to make sure nothing is amiss.
Naming Custom Fields and Key Values
Aside from random weirdness of the database kind, watch out for this database-related glitch: renaming your custom fields from the default “Key_x” which is automatically assigned when you create a new one.
To my understanding, DirectoryPress allows you to replace the default name value with one more to your liking. For example, I initially named the custom field I created for a LinkedIn Profile “linkedin.”
At that time, I hadn’t attempted to use these custom fields for anything other than displaying them on the directory’s Listing Submission Page so customers could easily fill in related info when they created their listing. One oddity I’d noticed was that this particular field (“linkedin”) never showed up on the form. But I had no idea why and hadn’t taken time to figure it out.
In a completely unrelated matter, I was using phpMyAdmin database management tool to kick some stray info out of the database. (Stray comments left behind by WooCommerce that couldn’t be removed in the normal way. They really ought to fix that!) While carefully looking in the database for anything else left behind by WooCommerce or any other plugin, I noticed the Key_0, Key_1, etc. values and recognized them as those custom field values from DirectoryPress. Passing on by those, I did a double-take when I thought about the custom names …
Hadn’t I renamed those generic values to something more reflective of the custom fields I’d created? Yes, indeed!
Fast-forward to why the LinkedIn Profile custom field wasn’t showing on the Listing Submission Page.
When it didn’t show up in my newly created custom tabs area, I recalled the anomaly in the database, and pulled up the DirectoryPress custom fields admin function. There was a custom name but the backend database didn’t reflect this custom name. Using phpMyAdmin I could see that DirectoryPress had kept the generic name initially assigned (Key_x) and was proceeding as if I’d never made any change in that regard.
Thus, it appears that while in theory we should be able to name our custom fields whatever we want, in practice DirectoryPress does not process the custom fields unless they are named according to the “Key_x” convention. I guess this is somehow hard-coded into DirectoryPress; a tech support question for another day. Of course, I might be off-base here and the truth will reveal itself further down the line. In the meantime, I’ve got a launch coming up.
Some battles are won by surrender.
The resolution: I renamed the LinkedIn custom field according the the “Key_x” convention. (I gave it a really high random number because I didn’t want to conflict with some other Key_x value that might have already been created.) Now this field shows up on the custom tab AND it shows up on the submission form.
Dealing With The Code and _single.php
If/Then Text Showing Above Custom Fields on Listing Page Tabs
Remember, I’m working with the code samples provided by SimonSwiss in his tutorial.
Once I got the custom fields to actually show up on the Listing Page, I encountered a little problem with bits of conditional code showing up right above the custom fields. The image above (which you just viewed) is how the custom fields should display; the image below is how they appeared with the if/then code bleeding through.
I resolved this by removing the IF/Then statements in Simon’s code for generating the tabs.
Of course, I still have the issue Simon was trying to head off: if no value has been entered for a custom field (i.e., no LinkedIn Profile URL), ideally the field will not even show up on the page. Since I’ve removed the bit of code that should handle this, ALL the fields show up, and if no value exists, it puts in the current page URL.
I hope to get this worked out. In order to avoid a surprising user experience, I’ve added a brief note to the tab so a user will know what to expect. Not the most graceful solution, but it will do until this can be resolved more satisfactorily.
Here’s a snippet of my modified custom tabs code without the If/Then statements.
<!-- LINKEDIN PROFILE URL --> <div class="full clearfix border_t box"> <p class="f_half left"><strong>LinkedIn Profile URL</strong></p> <p class="f_half left">» <a href="<?php echo get_post_meta($post->ID, 'Key_5932', true) ?>" target="_blank" rel="nofollow">See what we share on G+</a></p>
Conditional Display Fixed
Now that the code works as intended, I can share the results with you. In case you need a more graphical representation of how this code works the conditional display magic, look further down for an explanation.
The two images below show a segment of the Listing Pages from two different small businesses. The one on the
left top has more social profiles showing than the one on the right bottom. This is the essence of conditional display; it only shows the custom fields and their information if the field has been filled in.
Here’s another example of conditionals at work. The directory Submission Page has an area where small businesses can fill in information about local write-ups and featured articles where they’ve been profiled. They can also indicate whether they have listed their business in other local or national directories (so customers can hop over and write reviews in them).
See how the “Other Directories” area is blank on this listing? Once the business adds information about Yelp or Google Local, that information will appear.
It’s A Wrap!
There are three things to pay close attention to in order to make sure the conditional portion of your code yields the correct results. The idea is that your statement is wrapped in this code.
- The number 1 indicates the start of the wrapper. It is the complete line of code beginning with < ? php if and ending with ? >.
- The number 2 indicates the end of the wrapper. It is the short chunk of code pointed to by the arrow.
- The third item of importance is to change the KEY VALUE in number 1 to match the KEY VALUE in the “echo get_post_meta” line. (Key Value is whatever name you have given your custom field. It might not begin with “key;” it could be “facebook” or “number_of_employees.”
DirectoryPress users: Let me know if it would be useful to have a copy of the file where this code goes (_single.php).
Brackets vs. HTML Entities
One other caveat to take into consideration about the code is something I mentioned in my comment on Simon’s tutorial.
… for some reason, some places in your code use the actual brackets “<" or ">” while other places use the html entities “< ;” or “> ; ” … Maybe it’s just my WP installations but I’ve run into this before where I have to switch out the entities and use the actual brackets, otherwise the code doesn’t work. I noted this here in case someone else runs into a similar problem.
Update: Simon indicated that a little code corruption had crept in. Fixed!
He weeded out the corruption. Take note that if your code somehow gets corrupted between copying and usage, you can easily fix that yourself by using the actual angle brackets
- wherever you see “< ;” substitute a left angle bracket (<)
- wherever you see “> ; substitute a right angle bracket (>)
All in all, SimonSwiss’s DirectoryPress tutorial on creating custom tabs was very straightforward, explained the steps adequately, and provided exact code snippets necessary for making changes. He’s a fellow after my own (teaching) heart!
Link to this page: