Over the last few weeks, I’ve talked about some of the changes that I’ve been looking to make over the coming weeks primarily so that I can re-focus my efforts. Specifically, I talked about this in this post and in this post.
One of the first changes that I needed to make was that of the WordPress Plugin Boilerplate.
A couple of weeks ago, I shared a quick tip on working with multiple InfoWindows with the Google Maps API specifically within the context of WordPress.
When working with this API, there are a number of considerations to take into account each of which is going to depend on how much of the API you’re going to be using; however, one constant that’s going to remain regardless of how much you’re using is the rate limit.
That is, unless you’ve paid Google a decent chunk of change, then you’re going to have to take rate limiting into account whenever you’re working with this API. And if you’re charting quite a few locations for, say, several different pages or several searches, then you can hit that limit quickly.
If you’re not at the point where you can pay Google to up the rate limit, but you’d like to still make sure your project doesn’t totally bomb out if the rate limit is hit, then I recommend using transients to store Google Maps data for an interval of time so that you aren’t making frequent calls to the API.
Generally speaking, people often set out to try to set their plans, goals, and resolutions at the beginning of the year. I did though it’s not really something I typically do, and here we are at the beginning of March and I’ve really only done a portion of what I thought I was going to be doing.
I mean, I haven’t even touched Swift yet (and I don’t know if I will end up doing so).
Then again, Pressware has been growing and has resulted in the need for me to make some changes both to what I’m doing with some of my open source plugins and with what I’m planning to do with the business itself.
It’s both an exciting time, but it’s also a really weird time because it’s causing me to evaluate some changes that I’m making in a number of things that I’ve been working on for several years at this point.
When this happens, I can’t help but feel a little bit of tension – maybe even some fear – of letting certain things go. On top of that, I think that it can also breed a sense of relief as it may bring about a little bit of breathing room.
But does it really? I mean, when we wind down work on one thing, are we just making space to spin up something new?
For me personally, what I’m finding out – and it’s sort of a cliche – is that the more things change, the more they stay the same.
Though I may be winding down certain things, other things are starting up.
For some time now, I’ve been a big fan of using WordPress for web application development, but I think that developers actually embracing the CMS (let alone seeing the CMS) as a foundation for something like that is still a couple of years off.
Sure, we’re going to see some people using it for things like that. I mean, we’re already seeing some out-of-the-box applications like AppPresser, but projects like that are the exceptio, not the rule. In my own experience, I’ve found that clients are very interested in using WordPress, but using it for more application-like capabilities.
This doesn’t mean that gigs for themes, plugins, and what not are slowing down, but that people are wanting web applications for themselves or their companies, but want to be able to administer it using the WordPress dashboard or using a some custom front-end work.
But that’s beside the point.
What I’m getting at is that as developers, designers, and other people end up seeing WordPress as potential foundation for web application development, the more innovative things we’re going to see entering the space.
Yesterday, I came across a comment that was in the context of a larger post that I think does an excellent job of highlighting what we – as theme developers – should be doing with our projects rather than what we’re currently doing.
For those who know @Rarst, this wisdom will come as no surprise, but for those of you who are new to theme development, or WordPress development of any kind, then I think you’ll find this insightful:
We can chuckle and point fingers at bundled plugin monstrosities. But the reason those monstrosities exist include WordPress strategically for years disregarding need for third party infrastructure and dependency management. It’s telling that it has been priority so low, that even backwards compatibility was broken on related parts of core without a second thought.
So how does this translate, exactly? That is, what is it that we’re doing or that we can do in order to make theme development, plugin development, or both much stronger, resilient, and generally better than what we’re doing now?
If you’re in the business of building plugins – regardless of if it’s for fun or profit – the odds that you’re eventually going to have to read the contents of a file are relatively high.
This could be for importing data from a file, this could be for parsing data out of something that a customer has provided, or this could just be used to help drive the user interface. Whatever the case, PHP offers a number of different functions for opening files and reading files.
This can be convenient, but in my experience, there’s one process that I’ve found to be more resilient than the other options when it comes to reading files and I thought I’d share the general process here.
Because WordPress is built using a number of languages none of which are compiled, it makes it completely possible to make things happen within your theme, plugin, or extension by circumventing the native APIs.
This means that if you wanted to, say, introduce some type of element on one of the dashboard screens or you wanted to introduce functionality into one of your templates that didn’t previously exist, there’s a strong chance that you’d be able to do so simply by “brute force.”
And by that, I mean that you’d be able to make something happen – and probably work correctly – without using the native set of APIs that are available.
But when you’re faced with that situation, I highly recommend taking a step back and determining if you’re approaching the problem in the best way possible given your set of constraints.
At some point, I think that many of us – if not all of us – have all been in a position where we feel like we have too much going on. Or, to use a cliché, we have too many irons in the fire.
In some ways, I think it’s a good thing. I mean, we’ve involved ourselves in a number of projects and activities all of which [hopefully] are contributing to something larger than ourselves for the betterment of the people around us, but, at the same time, we continue to add to this list of responsibilities that we have.
The thing is, those responsibilities may come in different forms. They don’t have to come in the form of projects that we’re working on on our computers or around the house, nor do they have to come in the form of something work related.
Perhaps your family changes in some way, perhaps you change in some way. Whatever the case, you find yourself looking for a little bit more margin – a little bit more breathing room so that you can either focus on all of the stuff that’s cropped up in your life, or so you can move on to higher priority projects.
The thing is, what are you supposed to remove that would ideally prevent the project from grinding to a halt all while making sure the right person takes the reigns to continue making sure that it stays in development (or whatever term works best here) and continues to benefit those who use it?
That’s the big question, right?
Last month, WP Chat held an “Ask Me Anything” or and AMA with Justin Tadlock. Justin, obviously a very popular, prolific, and respectable person in the WordPress economy, provided a great time even for those of us who were simply reading along (or for those who want to read along).
WP Chat is going to be making this a monthly event and I’m humbled to say that I’ll be participating in the next AMA session at WPChat on Monday night.
Recently, I’ve been working with the Google Maps API in order to plot locations that are stored as custom post type meta data in the WordPress database.
The general functionality is as follows:
The information windows that sit above the flags are also called infowindow within the context of the API.
The Google Maps API documentation is pretty good in covering stuff like this, but I did run into a couple of gotchas when working with it, so I thought I’d document them here just in case anyone runs into the same problem.
