When you’re working with a collection in PHP, most notably, arrays in PHP, there are two ways in which you primarily see the information manipulated:
through for loops,
through a variety of the array functions that PHP provides.
For what it’s worth, I think the array functions provide greater readability but they have been shown to be slower (especially with larger data – with smaller data, it’s naturally going to be negligible).
I often work with for loops and related functions to achieve the same thing but I thought it might be worth look at an example from the previous post and how I used the array functions to achieve the same things as a for loop.
Ultimately, this is is a comparison post but I think it’s good to see how the same code can be written in different ways.
As many of us continue to move forward with PHP7+, we can continue to take advantage of a lot of new features that the language offers.
In the meantime, though, there are still features of PHP and related software that we can use t help streamline our development. The least of which (and that which I’ve written and spoken about a bit) is namespaces.
Here’s the thing, though: I like to have my plugin’s files and directories structured so that they are organized to mirror that of the namespace conventions they follow. And this can be done for taxonomies, meta boxes, domain objects, database-related functionality and so on.
In this post, though, I want to talk about a way of organizing WordPress settings screens from both the logical – that is, their file system location – and the virtual – that is, their namespaces – organizational structures.
If you treat WordPress exclusively as a blogging application or, even in a more liberal sense, a content management system, then you’re likely used to using the editor or the excerpt field to write a teaser then introduce a Read More link.
WordPress for Web Applications (Again)
For those who have read this site for a while, I’m specifically interested in using WordPress as a foundation for web application development (see also this, this, this, and this).
So there are times when the content that you’re going to be rendering on the front-end may be coming from a third-party source.
Back to the Content
That is, the application works like this:
contact a third-party API,
import data from the call and parse it as necessary,
write it to the database,
render the information on the front-end when requested.
There’s a lot that can go in between each of the above steps, but the main thing I want to share in this post is an effective way to easily truncate text using PHP to render on the front-end.
This is useful for providing teasers, linking out to third-party sites, and more all without needing to write or edit content manually.
And that’s the content that I have for site members thus far. But that doesn’t answer the question of what’s next (nor does it answer the question as to why I’ve laid things out the way that I have), so I thought I’d take a post to do that.
When you write enough code that communicates with third-party APIs, you’re more than likely going to find yourself communicating with an XML-based API.
And say what you will about it: Some like it, some don’t. But they exist, and they are thus going to be a necessary part of your development at some point.
If the API is well-designed, it will likely use namespaces for different types of requests and responses. And when you’re writing the client for said API, then you’re likely going to need to go about retrieving namespaced properties.
It’s easy to do it, but it’s not immediately obvious. So in this post, I’m going to walk through an example of how to do just that.