This Wednesday, July 25th, I’ll be speaking to the Atlanta WordPress Users Group about WordPress plugins.
Specifically, I’ll be leading two discussions:
Author: Tom (Page 385 of 424)
Recently, someone asked me if a given theme was compatible with another popular WordPress framework. The short answer is that no, it was not, but it did get me thinking: If there’s one word that’s becoming all too common in the WordPress space, it’s “framework.”
If you were to ask a handful of people to define “framework,” you would probably hear one of two things:
- Novice-to-experienced bloggers would say that it’s a theme with a variety of customization options
- Developers would say that it’s a way to more easily build a theme
I’m sure there are a few other responses but, generally speaking, this is what I hear and read the most.
Instead, I think that “framework” is way over used in the WordPress world and the lack of understanding has the potential to negatively affect both bloggers and younger developers.
In my experience, one of the biggest pet peeves that others have with hiring developers to build a product for them, is that the client and the developer have completely different ideas as to what it means to be “done.”
By that, I mean developers (especially younger developers) consider a project to be done when the code has been written. But, come on, there’s so much more to it than that – aside from the usual staging enivronment, testing, and deployment, there’s also the issue of support.
Support looks different based on the nature of the product: Some may need on-going support via forums, some may need maintenance, others may need some form of documentation or a manual.
Up to this point, providing documentation for WordPress-based projects has normally been relegated to something like README files or websites, but as WordPress continues to become a more popular foundation for building not only sites and blogs, but applications, too, the need for solid documentation is only increasing.
Last night, we hosted our Standard Theme Migration Meetup. We had a solid turnout – there was an even split of 50 or so people hanging out with us face-to-face and via the webcast.
During the meetup, John did a live migration of his blog over to Standard 3 showing everyone his process for how to safely update their blog and I discussed WordPress’ custom menu system, header images, header text, Standard’s header logo feature, and some of the other features built into the theme.
If you're an advanced developer or just want the TL;DR version of this, skip to the code.
For many, creating WordPress posts and pages is a simple matter of using the built-in editor. But if you’re working on a more advanced project – perhaps you need to automatically generate pages (or posts) to act as views or to restrict users from accessing the dashboard.
If that’s the case, then it may be better to programmatically create a post in WordPress.
Case in point: I’ve been working on a project where all user profile management (save for administrators) has to occur outside of the dashboard. This means that when the theme is installed, it needs to automatically generate pages that support this functionality.
It’s not terribly difficult, but it’s important to make sure that you aren’t overwriting existing pages, that you’re properly setting post attributes, and that you’re properly assigning templates when necessary.
Here’s a simple example of how to programmatically create a post in WordPress.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.