Someone asked me today how to use WP_Query to get posts by a relative date. The codex provides an example on how to achieve this. Heres what is shown on the codex.
I feel that its sloppy and not very flexible. Having to add the filter and remove it each time you want to do this is ugly. I solved this some time ago and had to dig through some old code to find it.
Ultimately what I have done is the same solution, using the same filter, and utilizing strtotime() to get the relative date. However i’ve wrapped it into a simple “since” parameter that can be used on any query. Just a little nicer and simpler to use.
This technique can easily be adapted to other custom parameters which result in modifications to the where or join filters.
Tricks for interacting with a branch, without checking it out.
Browse a directory (like ls):
git show [ref]:[path]
> git show master:your/path/
See contents of a file (command as above):
git show [ref]:[filepath]
> git show master:your/path/file.php
Checkout a specific file or directory from a different branch:
git checkout [ref] -- [path]
> git checkout master -- your/path/file.php
Note: There are other ways to do similar tasks such as `git ls-tree` and they may have more options. However I find these to be more accessible and easy to remember.
I just ran into a little gotcha with regard how fetch handles tags. When it pulls down commits, you will usually see that it also pulls down tags. I was a little confused today when fetch was refusing to pull a tag that was clearly in the repository (“
git ls-remote --tags“) lets you see tags available on the remote).
I kept running the fetch command but the tag wouldn’t get pulled down. The reason has to do with the way fetch works, it only fetches tags that are direct references to a commit that is in a branch being fetched. To get all tags regardless of what commits they reference use the fetch in the following way.
From the git manual (“git help fetch”):
-t, –tags Most of the tags are fetched automatically as branch heads are downloaded, but tags that do not point at objects reachable from the branch heads that are being tracked will not be fetched by this mechanism. This flag lets all tags and their associated objects be downloaded. The default behavior for a remote may be specified with the remote.<name>.tagopt setting. See git-config(1).
This will effectively do the inverse of normal fetch. It will fetch all tags, and bring with is any necessary commits.
Hope this helps some poor confused folks out there a little bit of greif.
Generally speaking Git is fantastic and easy to use – one of the few pain points is where submodules butt heads with branches.
Far from solving all the problems in related to this – I’ve found an
easy way to find out what submodules are in a branch, commit, or tag without having to check that reference out. This method also shows you the commits that each submodule is currently pointing to.
The ls-tree command is fairly simple, its like running the ls unix command but includes git information – like the type of object each item is and the hash reference for that object. That command can also be used on a specific directory also by using <reference>:<path>. The -r flag makes it recursive so that is searches through all the subdirectories in the branch.
The second part of this is a simple grep command, that filters the results by those of type “commit”, which is how ls-tree represents submodules. I’ve included a pattern to match the word commit followed by the SHA1 hash – to avoid getting items that have the word commit as part of a folder or filename.
Hope this helps someone out there – it took me a while to figure out how to do this.
In the past I’ve mentioned a very complex plugin named “WidgetPress”, which I built and is the underlying foundation of the Sears Community and Kmart Community sites. What WidgetPress does is complex, and the short time I had did not allow me to really clean it up the way I would have liked to. This is why I have not released it publicly.
However, the lessons learned from WidgetPress are many, and some of the ideas and solutions that led to its completion can be feathered out of the bulky plugin into their own stand-alone plugins. Thats exactly what I am trying to do now. The specific functionality I’m working on right now is the idea of using custom post types and taxonomies in such a way that they are no longer independent. It will take some explaining to show how this is useful so I will start by explaining how it is used in WidgetPress.
WidgetPress, at the end of the day just lets admin’s create “Section Fronts” based on category or a Page – define their layout, and drop widgets into them to determine the entire contents of that layout. The widgets themselves make up as much of the page as the theme developer likes – for our purposes, everything between the top navigation and the button navigation is entirely composed of widgets on almost every single page on the site.
For WidgetPress to work, I actually had to completely deconstruct and reengineer the way WordPress handles widgets internally. I completely bypass WP_Widget_Factory, I ignore all those horrible global arrays, and hijack the whole widget registration process. I built my own entire structure for handling widgets, while still allowing (most) normal WordPress widgets to function without a hitch. I could write a whole book about the reasons I had to rebuilt all this but I’ll skip that. In my implementation Widgets are actually a post type, and sidebars are constructed using a custom post type AND a custom taxonomy working together – not in the typical way posts and categories work together – instead the post type and taxonomy function as a single entity. When an admin creates a sidebar, in the background it creates a new post of that post type, and a new term for that taxonomy.
The flexibility this allows is not immediately obvious. Widgets being a post type mean that they exist independent of their actual sidebar. Sidebars being a taxonomy means widgets can be placed into any number of sidebars, and sidebars can be associated with any number of “Pages”, “Posts” or other post types registered for that taxonomy. Sidebars, being a taxonomy and a post type, means that although they are used primarily as a taxonomy – each term can actually store meta data! This is the functionality that today I am building into a separate component.
The project I’m doing this is completely different from WidgetPress, its actually for an in-house products plugin – the intention being that any bit of data about each product can easily be made to be meta data and/or a taxonomy term.
The working name for this is WP_Node. I realize “node” has all sorts of existing meanings and connotations. However, given the way this merges content and relationships, blending them into a single idea – I find it difficult to think of a term that fits it better while remaining as abstract as it should be.
Hopefully in the coming months I’ll be able to release WP_Node (or whatever I end up calling it), as an independent library or plugin. There are also several other very interesting things I’d like to pull out of WidgetPress – maybe at the end of all this I can rebuild WidgetPress using the separate components (each of which will be better thought out and better written).
A user of the Incorrect Datetime Bug Fix plugin submitted a bug report last week. While the plugin was turned on the user was getting an error about improper usage of wpdb::prepare() in WordPress 3.5.
Warning: Missing argument 2 for wpdb::prepare()
This threw me for a loop, since its such a simple plugin that I’ve never had to change, I assumed that something changed in the new version of WordPress 3.5. I was all ready to submit a new trac ticket. As it turns out, it was my usage of wpdb::prepare() that had always been incorrect, if you are a developer and are interested in knowing more about the problem, read Andrew Nacin’s article on the subject. In the past WordPress simply wasn’t throwing out an error and that’s what was changed in WordPress 3.5. I found this by using git’s “bisect” feature, which is really great and I might write a blog post about it in the future.
As always I greatly appreciate but reports, idea submissions for my plugins, and any other feedback regarding the plugins I maintain. It is whats great about Open Source and it helps me validate its usage in the corporate world. The new version is now available for download. Please update to avoid these errors from being reported.
Last week I finally released Media Categories 1.5, but I neglected to write a post about it. Most of the UI issues have been resolved with the Media Modal, however due tot time constraints I could only ensure the plugins compatibility as far back as WordPress 3.3. It doesn’t break the site earlier than that, but selected taxonomy terms dont save properly. As of now, I have no plans to extend support to 3.2.x or before.
I do intend however on adding a few more features that I think are missing from WordPress 3.5 as soon as I have the time. The most obvious of which I will also try to get committed to core. Said enhancements include:
- Fixing the counter on the right of the attachment table – its supposed to indicate the number of media items per category but it does not count accurately.
- Adding a taxonomy filter to the attachments page – for most post types with a taxonomy enabled, the post types admin page shows a ‘View all categories’ drop down. This is missing from media in WordPress 3.5. I would also try to work some similar filtering ability into the Media Modal.
- There seem to still be some UI issues in the Media Modal when multiple taxonomies are assigned to a post type.
- I may create an admin interface in the settings area to allow admins to simply check from a list of checkboxes, which taxonomies (of all available taxonomies) they would like to enable for media.
- I may also include some simple functions for retrieving attachments by taxonomy. Although these would essentially be a simple wrappers of WP_Query or one of its wrapper functions, I believe it would serve as an example to developers on how to get started.
Take a look at how great attachments with taxonomies look in WordPress 3.5 by downloading Media Categories 1.5. Look out for some of these improvements I mentioned above in the next version, Media Categories 1.6.
One additional note: At some point in the near future I will update the plugins pages on this site,… I promise. However, please understand that the pages on this site are meant to contain the same information as the WordPress plugin repository does, mostly in the ‘Other Notes’ tab.