studentrob

Pretty sure that is the same thing I came up with in my second comment. The rest of this thread was just discussion with the author on the feasibility of adding sorting by a custom date field to the plugin GUI.

I think you are missing my major gripe about how migrations are not streamlined in WP but it they are for other CMSs. Links in post content need not be stored as full URLs, and the action attribute on the WP login form need not contain the full site URL.

To your points,

Easier search/replaces

Even with the current setup you have to do a search/replace for relative URLs too because content editors may have chosen to use them. Surely one could write a plugin to cover the cases.

Works well with all feeds (relative URLs don;’t)

When you make a feed obviously you would generate the full URL

Not having to run a query to check the URL every time you want to load a link or image

Huh?

Easier support with dynamically generated content (if this was a static HTML site, I’d agree with relative URLs, but WP is all dynamic and things get moved)

Is this the same point as above?

Backwards compatibility

Nothing about storing newly created URLs as relative ones by default in post content would break old versions of WordPress. Nothing about changing the form’s action path would break an existing user’s site.

Ipstenu- anything substantive would do.

Again, this response is just a defense of the current setup, and does not address specifics. “It’s easier to search/replace a full path in the long run,” or “It’s been that way for 9 years” are not legitimate reasons. Hopefully you do not apply such logic to civil liberties.

Why is search/replace easier than not having to do so? Do you mean that it is easier to keep the current setup than to change core code? If so, nearly all programming problems are this way!

Again, I understand there are ways to do the search/replace if you add them to your system, and I also realize that everyone may not need these tools so that is why they come packaged separately.

What I do not understand is why not fix the simple things, like the action of the link button in the WYSIWYG when selecting your own content to link to, or the uploaded content images and site logo – why not just have these store a relative paths to my own content rather than the absolute url?

To migrate WP you must take some steps before you can log in to your new site. Other CMSs do not have this requirement, why should WP?

You link to 472 posts. I see some people with the same question as me, one guy who claims it is easier to migrate a site with absolute URLs than it is to migrate one that uses relative URLs (not sure what he is thinking), and some suggestions on how to implement a WordPress migration. I do not see anything about why WP stores domain + full path in various places. Nor is there any explanation why the process of migration between dev/test/prod environments is not more streamlined.

I found a solution to my problem in the plugin Quick Page/Post Redirect .. I can create a fake page that redirects and shows its link as the redirect page in the menu. It might still be cool to be able to use this plugin with a custom menu though

Well I am glad we are on the same page anyway =). Perhaps it is a bug or oversight that we can report somewhere.

I tried putting these for type: NUMERIC, DATE, DATETIME, and TIME

None worked. The SQL that is produced does not contain any comparison of the date field.

I don’t really understand the documentation for WP_Query with respect to filtering on custom fields. I do not see a distinction being made between using meta_value_num along with meta_compare vs. putting everything in meta_query.

Also, in the examples for date comparison (search for the text “Return posts 30 to 60 days old”), they use filter overrides and it seems sort of hackish but that is the only way I could get this to work.

Let me know if you get meta_query to work!

Thanks for offering to take a look at my code! (FYI for anyone reading- this is not really relevant to the use of Query Wrangler)

Regarding posts_orderby — it is a filter. It allows you to append to or replace the order by expression in the executed query.

Before resorting to using the filters, I tried this,

$query = new WP_Query( array(
      'post_type' => 'event',
      'posts_per_page' => 3,
      'post_status' => 'publish',
      'meta_key' => 'wpcf-event-date',
      'meta_value_num' => time(),
      'meta_compare' => '>=',
      'orderby' => 'meta_value_num',
    ));

The SQL that is spit out is,

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) WHERE 1=1 AND wp_posts.post_type = 'event' AND (wp_posts.post_status = 'publish') AND (wp_postmeta.meta_key = 'wpcf-event-date' ) GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value+0 DESC LIMIT 0, 3

In the above SQL, the comparison is not included and I do not see any PHP error indicating why. If I change the meta_value_num parameter above to be meta_value,

'meta_value' => time(),

then I get the below SQL which includes the comparison, however the meta_value comparison is done as a string which is no good,

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) WHERE 1=1 AND wp_posts.post_type = 'event' AND (wp_posts.post_status = 'publish') AND ( (wp_postmeta.meta_key = 'wpcf-event-date' AND CAST(wp_postmeta.meta_value AS CHAR) >= '1345912223') ) GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value+0 DESC LIMIT 0, 3

Any ideas? Also, in query wrangler, is it possible to filter by a custom date field using > and < ? Thanks again!

Cool. I wrote my own widget this time and used WP_Query, along with filters posts_where and posts_orderby to solve my problem.

I checked out 1.6 anyway because I was curious how you handled the filtering. I see the filters for meta_key and meta_value. I was expecting to see a filter for the specific field but this works just fine.

How does the meta_value filter work? In the box, is it expecting a particular value to equate? In my case I actually wanted to filter by a custom field that is a date, and use comparisons like > or <. I believe this would require a more advanced filter due to the way WP stores custom fields. So I would leave “filtering by custom field that is a date” as an open request for this plugin.

Since custom fields are all stored in the same table and column, the database does not know its type. Unless I am missing something like the type is stored in another table, it seems as if the database only knows them as varchars. I wonder why WP chose to store all custom fields in one table rather than creating new tables & columns like in Drupal. In the future I could see this causing problems with scalability too.

Anyway, in my case, since the custom date field I created is stored as unix time (seconds since epoch), I need to explicitly convert it in the filters.

Maybe you could use the plugin Types to add two more custom fields to your Post, put the images into separate fields, then in your query, choose row style fields and pick one of the image fields.

I would argue this is simply not a well tested plugin. I’ve no idea why WP decided to advertise it in 3.3 as a new feature. I have not been able to get it to work well either. I highly recommend running this on a development copy of your site first.

Otto, are you saying that the importer will only process and import the first image in any tumblr post?

What does the changelog mean where it says it handles multi image posts in .3 and .4?