Need help updating WordPress query so that it treats longtext column data as integer data

I'm trying to figure out how to update this WordPress query so that it treats the value of the "post_content_filtered" column as an integer, but so far I haven't had any luck. I believe  it's because the data type for that column is set to "longtext", and since it's once of the native columns within the wp_posts table -- I'm reluctant to change the structure:

 $ytd_active_listings_args = array(
    'post_type' => 'wwu_ytd_active_list',
    'numberposts' => '-1',
    'post_status' => 'any', 
    'orderby' => 'post_content_filtered',
    'order' => 'DESC' 
  ); 

  $ytd_active_listings_data = get_posts( $ytd_active_listings_args );

Open in new window


The values that are contained within the "post_content_filtered" column are numeric -- more specifically --- dollar values -- although they DO NOT contain any dollar signs, commas or decimals. They're just in the format of "12050000", "350000", "265000", etc.  I've been trying to order these rows in descending order, meaning from lowest price to highest price, .. but it appears that I've hit a brick wall.  Adding additional custom fields is not an option, ... and changing the data type of the "post_content_filtered" column is also not an option.  So what options remain, if any?

Thanks,
- Yvan
egoselfaxisAsked:
Who is Participating?
 
gr8gonzoConsultantCommented:
Haven't tested this yet, but you should be able to perform a usort on the results:

usort($ytd_active_listings_data, 'sort_by_post_content_filtered');
function sort_by_post_content_filtered($a, $b)
{
    return (0+$b->post_content_filtered) - (0+$a->post_content_filtered);  // Descending order, swap $a and $b if you want ascending
}

Open in new window

1
 
egoselfaxisAuthor Commented:
Should I place this code snippet in my plugin .. or in my child theme's functions.php file?  And how would I apply it to my result set?

- Yvan
0
 
Steve BinkCommented:
Some thoughts:

1) Your data is being stored in MySQL as text, and any sorting you do in the query will be implemented as a textual sort.  Given the restrictions you noted, there is no way for you to alter this.  That means, given the values 20, 2, 1, and 10, your sort will be (1, 10, 2, 20).

2) gr8gonzo's usort() suggestion is probably the easiest way to do this.  Note that this sort is done in PHP, not MySQL, so it will be slower, but it also allows for type conversion.  Also, I would prefer to use typecasting rather than implicit conversion.  E.g.,
// $integer_value = (int) $b->number_as_text;
function sort_by_post_content_filtered($a, $b)
{
    return ((int)$b->post_content_filtered) - ((int)$a->post_content_filtered);  // Descending order, swap $a and $b if you want ascending
}

Open in new window


3) The ideal solution here is to create data structures which are appropriate for your data.  If the table in Wordpress is not designed to hold and manipulate this data appropriately, it behooves you (as the developer) to design a solution which does.  Hacks like this will only complicate your life as you move forward.
0
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

 
gr8gonzoConsultantCommented:
@Steve - Whenever I don't know what the numeric values might be, or what PHP build will be used, and I see samples that have a wide range (e.g. "12050000", "350000", "265000"), I use the implicit conversion just in case the values go above the maximum int size.

For example, go grab a 32-bit copy of PHP 5.x and go run this code:
<?php
$x = "15147483648";
var_dump($x + 0);
var_dump((int)$x);

Open in new window


You'll see two different outputs:
float(15147483648)
int(2147483647)

Open in new window


So usually using a +0 for unknown numerical ranges is a little safer. Plus, if there are any decimal values in play, the +0 approach won't truncate the precision data.
0
 
egoselfaxisAuthor Commented:
I entirely agree with you that this could have been planned more efficiently.  I made the conscious choice to work within the narrow confines of an unmodified wp_posts table, and now I'm just looking for a quick and effective patch/solution .. which I'm excited to try (thank you both for your help and feedback).  

So should I place the code snippet in my custom plugin file? Or should I place it in my child theme's functions.php file?  And how exactly would I apply this to my result set?  

- Yvan
0
 
gr8gonzoConsultantCommented:
@egoselfaxis - You would place my code snippet right after your get_posts() call. Given that your query isn't native WP code, I assumed you were already working within some custom code file, like a plugin or theme functions.
0
 
egoselfaxisAuthor Commented:
But what if I have 6 different get_posts() queries on the same page, .. where the other 5 queries are instead sorting based on the "post_order" column?  Will it only effect the 1 query, .. or all of them?

---- EDIT ----

Ah .. I see.  You're implicitly referencing the specific query:
usort([b]$ytd_active_listings_data[/b], 'sort_by_post_content_filtered');

Open in new window


Let me give this a try and I'll report back.

- Yvan

- Yvan
0
 
Steve BinkCommented:
@gr8gonzo:

>  I use the implicit conversion just in case the values go above the maximum int size.

Valid.  I have not been in a 32-bit environment for PHP in quite some time, so I tend to neglect those use cases.  And to be clear, in 64-bit, there is no functional difference - only semantics.  I prefer the typecasting because it makes the code's intent clear on a quick read.
0
 
Steve BinkCommented:
>>> I entirely agree with you that this could have been planned more efficiently.  
>>> I made the conscious choice to work within the narrow confines of an
>>> unmodified wp_posts table, and now I'm just looking for a quick and effective
>>> patch/solution .

I'd just like to point out the cycle you are already in...  The initial decision to work inside a slightly inappropriate schema instigates the need for work-around hacks, which cause other weird issues which require their own hacks, and so on.   One hack leads to another.  Each individual hack only needs enough work to resolve the single predecessor issue, while reversing the initial decision would require throwing away the entire "tree" of work-arounds.  It is a trap, though... a slippery slope.  In the long run, it is better to back it out and do it right.

I sympathize, though.  I'm currently in the middle of devising work-arounds to poor design decisions made by previous teams.  I can't back out the "bad" work because the project manager does not want to invest time in resolving "technical debt"...deadlines and whatnot.
0
 
gr8gonzoConsultantCommented:
I have not been in a 32-bit environment for PHP in quite some time
Yep, I know - I'm in the same boat. The only reason I caught it was because I had to fix an error due to this on a completely unrelated site.

However, the decimal thing is still a potential issue even on newer 64-bit versions. If you're certain there's no decimal data, then I'd agree that (int) is likely the better way to go. It's funny - I remember a time a long while ago when I thought PHP was better because it wasn't strongly-typed. :)
0
 
egoselfaxisAuthor Commented:
Thank you both for your assistance.  The custom method that was suggested is working as expected.

- Yvan
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.