Should have read:
This works correctly if it is surrounded by
...
, but is oorly formatted.
Hello,
first of all I am happy you’re finding this plugin useful for your needs!
On my test sites this shortcode is working fine:
[pissc post_type=post number=-1 orderby=meta_value order=DESC post_status=publish ignore_sticky=1 mq_key_aa=date mq_value_aa=now mq_compare_aa=> mq_type_aa=DATETIME custom_field=1 meta=date custom_field_txt=Event_date: debug_query=1]
Only make sure that the date stored in the custom field of the post has the same date format as in your WordPress preferences.
<p>Thanks for the quick reply.
I have been experimenting using the classic editor on my test site. pissc shortcodes seem to work correctly provided they don’t contain > or <. When they contain the comparison ‘>’, they generally act as if the comparison is ‘=’ or unknown. However, if the shortcode is surrounded by
and
, it works. Thus</p>
<p>
[pissc orderby=meta_value mq_key_aa=date mq_value_aa =now mq_compare_aa ='>' mq_type_aa =DATETIME"]
</p>
<p>works: it gives the right posts in the right order, but the result is, as was specified, pre-formatted. If
and
are omitted, it gives “no posts yet”.</p>
<p>Your example also works within
and
, but only if > is changed to ‘>’. If > is left as it is, it behaves as if the ‘>’ is ‘=’.</p>
<p>My assumption is that it is related to the fact that < and > have to be coded, but beyond that I remain mystified.</p>
Very sorry, I’m having terrible trouble with the formatting. I’ll try again later.
Let me have another go. There appears to be no way to preview one’s post, so with the large amount of embedded html, fingers vey much crossed:
I have been experimenting using the classic editor on my test site. All pissc shortcodes appear to work, provided they don’t contain > or <. Also, the following:
<pre> [pissc orderby=meta_value mq_key_aa=date mq_value_aa =2021-05-01 mq_compare_aa ='>' mq_type_aa =DATETIME"] </pre>
works. It gives the right posts in the right order, but it is, as specified, pre-formatted. If
and
are omitted, it gives “no posts yet”.
Your example also works similarly within
and
, but only if > is changed to ‘>’. If > is left as it is, it behaves as if the > is ‘=’.
Again, without the
and
it gives “no posts yet”.
My assumption is that it must be related to the fact that > and < have to be coded. I’ve tried various browsers and the block editor with similar but not identical results. I remain mystified.
Failed again.
Basically, the problem is that if the shortcode contains ‘>’, I cannot get it to work unless it is surrounded by a pre and /pre.
I would to help you, but I am unable to understand the situation if the code you write is stripped out by the forum engine. When you write the message in the forum, make sure to use correctly the code tag. Surround the code between two backticks or use the button above the editor. Or use a pastebin service and write here the link to the code.
Will do.
For the moment, I’ve hacked your code in pis-functions-queries.php to allow GT,GE,LT,LE as comparison options with the obvious meanings, so that’s circumvented the problem for the moment and taken the urgency away. But it would be much better to get to the bottom of it.
Essentially, if the shortcode comparison contains > or < it fails to produce the correct result (producing what = would). The only exception appears to be if the comparison is > and the code is enclosed in pre and /pre tags. Examples in the link.
For simplicity, there are 4 posts, dated using a meta ‘date’ field in April, May, June and July. The comparison is with the date May 1st.
Link to example
You can’t wrap a shortcode inside a pre tag. I gave you an example of a correct shortcode above.
Also make sure that there are no spaces before and after the equal character.
Finally, make sure that the date stored in the custom field is YYYY-MM-DD, i.e. for example 2021-05-15 (for 15th May 2021).
Thank you. It works now!
The problem was that I originally wrote (in html): mq_compare_aa=> as suggested by your example. This does not appear to work. I was originally reluctant to write mq_compare_aa=> which looked as if it would confuse the parsing. So wrote mq_compare_aa=’>’. This does work if surrounded by pre and /pre tags, but not otherwise.
But writing mq_compare_aa=> works under both circumstances.
If you are interested,
here are the results of some experiments.
Thanks very much for your patience.
