plaidflannel

RESOLVED: Programmer error. The shortcode was designed for category archives and worked there; changing to a tag archive for “budget” broke the shortcode.

Thanks. I now understand what you are saying.

My tag.php file included:

// determine the tag to be displayed
$tag = get_queried_object()->slug;

but I now realize that is not necessary.

I had originally created tag-budget.php and tag-election.php files. Then I realized that they were almost identical, differing only in the query, so I combined them.

The page for my budget posts needs to be substantially different from my main page, hence the need for both index.php and tag.php. My budget page and my election page may also be different, so it looks like my best solution is to have separate tag-budget.php and tag-election.php templates.

I still need a solution for the missing shortcode expansion though.

I agree that I will eventually need to set a reasonable value for posts_per_page.

I don’t see how to avoid doing a query in tag.php. How else can I limit the posts on that page to those that have the “budget” tag? (I also have a page that displays only posts with the “election” tag, and I anticipate other tag-specific pages.)

But back to the main problem. Is there a way to confirm that the problem is in the shortcode handler? I would prefer to avoid tracking down the source code for the handler and trying to understand it sufficiently well to make a change myself.

I am aware of the “do_shortcode()” function, but I’ve never used it. Is this a situation where it might be applicable?

Update: This problem has been solved. The culprit was an extraneous “?>” in the child theme archive.php file. It was located in the name of a CSS class, resulting in the real CSS class not being applied to the sidebar.

Thanks for your offer of help.

Because I needed hierarchical FAQ groups, I created my own custom taxonomy. In the template for my FAQ page, I added code to fetch the names of subgroups of the queried FAQ group. Those names were used to create an HTML tag ID and a jQuery accordion for each subgroup. Then I could display all the subgroups on one page.

The loading problem and the CSS problem no longer occurred.

It would take me more time than I wish to spend to reconstruct the original problem.

I have tried my shortcode with two other themes: my parent theme (Zita) and Clearex. I get the same results as detailed in my original post.

The kludge mentioned in my original post works. Fortunately, my captions are such that it is usually easy to know when a line break will be needed. So, for know, that’s what I am doing.

Question to moderator: does having a workaround count as having my question resolved? Or should it remain open in the hope that the cause of the problem will ultimately be identified?

Thanks.

It is bedtime in my timezone right now, so I’ll be a day or so getting back to this.

You said, “add this shortcode: [mycode photo=’photo URL’ cap=’my caption<br />text here’]”

That is exactly what I tried first (see paragraphs 4 and 5 of my original post).

The link https://9588b561.ngrok.io/hello-world/ gets me to a page containing only:

Tunnel 9588b561.ngrok.io not found

You said, “Can you please confirm your code in another theme.”

My code is deep in a child theme. I’m not sure I can test it easily in another theme without building at least a little bit of a new child theme. Or is it as simple as adding a copy of my shortcodes.php file to that other theme?

I found a different, maybe better approach…

My original task was populating a table with five to ten cells. Each cell used “float: left” to fill a number of columns (typically three) that would vary with screen width. The shortcode parameters were an image and a caption for each cell.

The new approach is to create separate shortcodes to open the table, add one cell, and close the table. This results in seven to twelve consecutive shortcodes, but each has no more than two parameters and thus is quite readable.

One problem is that having consecutive shortcodes separated by a single linefeed results in “<br /> being inserted between them by the shortcode parser. That messes up the formatting of the table.

To solve that problem, I put two linefeeds between consecutive shortcodes. The table then formats correctly.

Thanks for the reply.

Let me try to clarify a few things.

First, my current (experimental) page template (committee-page.php) contains pieces of code like this:

$args = array('category_name'=>'budget','tag'=>'intro');
$the_query = new WP_Query($args);
if ( $the_query->have_posts() ) {
  $the_query->the_post();
  get_template_part( 'template-parts/content', 'page' );
}

There are similar chunks for the members, most recent agenda, and three most recent minutes.

Notice that the category slug is hard-coded in the template, so I would need 20 almost identical page templates to handle the 20 committees. Obviously, I would like to avoid this if possible.

The difficulty, it seems, is that a committee page is built from posts that require very specific WP_Query() arguments. I see no other way to assemble those posts that to make several separate queries.

This also means that some posts are displayed in two or more different contexts, and will be formatted somewhat differently in each context. So the post itself cannot use a single tag or field or custom type to identify in advance the context in which it will be used.

Is there an alternative to using PHP parameters? For example, can my committee-page.php template discover attributes (URL, category, tag, custom field) of the page that is being constructed from that template? Those attributes might provide enough information to recover the category slug that I need, rather than having it hard-coded.

I explored my issue a bit further and discovered that the text I was copying and pasting actually has a space character on the supposedly blank lines between paragraphs. So there was never an occurrence of two consecutive line feeds (or returns).

If I pre-edit my text to remove those space characters, then the pasting works.

I can also post-edit my text by placing the cursor where each of the paragraph breaks should be and hitting return. That restores the paragraph structure.

Neither of these is ideal, but it is not the fault of Gutenberg.

Additional experiments seem to indicate that anywhere I call a PHP date/time function, I need to precede it with:
<?php date_default_timezone_set(“America/Denver”); ?>

I assume that the WordPress editor does whatever is necessary whenever a post is published or updated, so the correct timestamp is saved in the post database. That may include checking the timezone in Settings/General. Does the editor also need to reset the PHP default timezone before every date/time action?

Also, what purpose does setting the default timezone in php.ini serve, if not to set the site-wide default?

Some background: I’m in the process of learning WordPress, refreshing my knowledge of PHP and CSS, and experimenting with modifying page templates. My site is live, but in a subdomain that I’ve not told anyone about. I’m currently using a child theme of Zita. I’m using the WP 4.9 editor for most of the site work, and using MacOS TextWrangler with an FTP client to develop and upload my PHP files.

I do most of my work in the daytime, before 5:00 pm. So the wrong dates on posts were not evident. An attempt to put the current date in my site header, using an addition to my index.php template, was giving the wrong date, and that was the first indicator of the problem. Several different PHP functions were tried, all without success. (But an inline javascript worked correctly: <script> document.write(new Date().toLocaleDateString()); </script>.)

A post today at 4:58 pm local time had the correct date; another post at 5:02 pm had the incorrect date (meaning tomorrow). That seemed to be evidence that my installation was using UTC.

I also noted that some of the PHP date-related functions produced a date in the future, while another produced a date in the past. Additional experiments the next day caused one of the PHP functions to produce a date two days in the past. That date (by coincidence?) was also the date of my last published post.

Some Google searches found suggestions that using the newer OOP PHP functions might give better results, but I’ve not gotten very far yet with experiments with that.

All of the above happened last week. During that week, I also upgraded my site to WordPress 5.0.1. I cannot say whether that upgrade instigated the erroneous dates on my posts—I just wasn’t paying attention before a few days ago.