Skip Navigation

[Resolved] Archive is not working? May be template related but not sure..

This support ticket is created 5 years ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+00:00)

This topic contains 9 replies, has 2 voices.

Last updated by markY-2 4 years, 12 months ago.

Assisted by: Nigel.

Author
Posts
#1415423

I am trying to: assign a custom archive to a custom post type. I believe it is assigned properly and the custom single template is working but the archive template is simply ignored.

Link to a page where the issue can be seen: hidden link

I expected to see: My custom wordpress archive. As a test, I wrote BOOGA BOOGA BOOGA at the bottom of my archive and it does not show up.

<div class="uk-align-left@m"><a href="[wpv-post-url]"><img width="320" height="320" src="[wpv-post-featured-image output="url"]" class="uk-border-circle" /></a></div>
<h2><a href="[wpv-post-url]">[wpv-post-title]</a></h2>
[wpv-post-body view_template="None"]
[wpv-post-read-more]
BOOGA BOOGA BOOGA

Instead, I got:
The archive page is not firing. I'm not sure why. I am using a custom built template so it could be due to that, but I'm not sure why since other archives work.

Via FTP, this may be where the issue lies. This is the portion of the code in my custom template that is running the check of if it is a post or a page.

I also just created an admin so you could log in and check in case this doesn't make sense. Thank you.

	if ( have_posts() ) :
		while ( have_posts() ) :
			the_post();
			if (is_page()) {
				/* 
				 * If this is a Page
				 */
				get_template_part( 'html/page', $post->post_name );
			} elseif (is_archive()) {
				/* 
				 * If this is an archive
				 */
				get_template_part( 'html/archive', single_cat_title('', false) );
			} elseif (is_home()) {
				/* 
				 * If this is on the homepage
				 */
				get_template_part( 'html/home', 'custom' );
			} else {
				/* 
				 * If this is a post
				 */
				if (get_post_type( get_the_ID() ) == 'post') {
					get_template_part( 'html/post', get_the_ID() );
				} else {
					/* 
					 * If this is a custom post type and it has a custom page template
					 */
					if (locate_template(array('html/' . get_post_type(get_the_ID()) . '.php', 'html/' . get_post_type(get_the_ID()) . '-' . get_the_ID() . '.php'))) {
						get_template_part( 'html/' . get_post_type(get_the_ID()), get_the_ID());
					} else {
						/* 
						 * Can't find a custom template for this type or post? Then, use the default post template
						 */
						get_template_part( 'html/post', get_the_ID() );
					}
					
				}
			}
#1416225

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

I tried to access your site but the password is incorrect.

I'll set up a private reply so that you can provide working credentials.

However, I can say that the likely cause is that your custom template for displaying archives does not use the native WordPress function the_content() to output the content, whereas your single post templates do (and hence work).

Can you check that?

You should be able to confirm that this is the problem if you switch to a default theme such as twentytwenty, where I expect your custom archives created with Toolset will display correctly.

#1416625
#1416697

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

I looked at your site to study the theme files, and things seem in order, I can't spot the problem.

So I'm taking a copy of the parent theme (which also has the problem) to test locally.

I'll get back to you with my findings (that will be tomorrow).

#1416755

Wow! That is above and beyond support! Thank you so much. I look forward to hearing what you find. I banged my head for quite a while trying to get it to work.

What I don't get is why the single template would work, normal post archives work fine, but the archive for the types/views custom post types would not.

Thank you.

#1418153

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

I installed your theme on a local test site and I can confirm that it doesn't display the custom archives.

I've looked through it and I can't spot the problem.

It uses the_content, so that if you create a Content Template and assign it to an archive, the content for each result of the archive does get replaced (not the title, not the featured image, just what the theme outputs for the post content. But if you want to replace the entire archive output, by creating a custom archive at Toolset > WordPress Archives, this depends on replacing everything within the standard WordPress loop.

And that's there in your theme templates, even though the template structure is very unusual, so I would expect it to work.

I'll need to pass this to my colleagues to take a closer look at, and I'll let you know what they find.

It may take a little while with Christmas looming.

#1437455

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Mark

It seems that the reason the archive doesn't work is because the custom archives in Toolset depend on an action triggered by the standard get_header call, and this theme doesn't use standard headers.

Our compatibility team would like to contact the theme author to discuss, could you please provide contact details?

#1442661

Sorry for the delay, with the holidays and all.

I am actually the original developer of this theme. This is an in-house theme framework I am developing with the intention to release open source at a later date. It should be following Worpress conventions but aims to introduce the UIKit framework (hidden link) with greater versatility down the road.

I was under the understanding that wp_head() function was the only part required for the header in order for WordPress plugins to function. That is included in index.php Line 21 for compatibility.

	<?php wp_head(); ?>

However, this might be okay since the header is included with get_template_part. Line 60, in that same index.php.

	switch ($section) {
		case "header":
		get_template_part('html/header', 'custom');
		break;

Perhaps we can change that to simply get_header('html/header','custom'). (Untested per https://developer.wordpress.org/reference/functions/get_header ).

Are you fairly confident that is whats causing the issue? If so, let me know and I can consult and attempt debugging.

For compatibility, this is the same with the footer, and I see there is a get_footer() as well. Are these fairly common functions/hooks used with WordPress plugins? I ask out of interest since I am not familiar with the plugin development side as much, so I greatly appreciate the feedback so that I can ensure the theme will be as compatible as possible.

Thank you for the above and beyond service and taking the time to diagnose and provide this (very helpful) feedback for me. If you could please let me know on the above I will debug and let you know. Thank you.

#1442811

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Rather than risk mis-communicating some detail to you let me get one of my colleagues that debugged this to contact you directly.

I'll check in with them in the morning and see what's best, I may re-assign this thread to them, but I'll let you know.

#1443959

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Let me share some feedback with you.

Your theme structure is highly unusual and doesn't follow the WordPress template hierarchy, even though you use the same file naming conventions, which is liable to cause confusion.

In your theme all requests go through index.php, which then gets template parts with names that are normally reserved for template files in the root directory.

So the template file for displaying single pages, page.php, would ordinarily reside in the root directory, and when a URL is visited for a single page WordPress will load page.php to build the entire page. If you look at a standard theme such as twentynineteen then the content looks like this:

<?php
get_header();
?>

	<section id="primary" class="content-area">
		<main id="main" class="site-main">

			<?php

			/* Start the Loop */
			while ( have_posts() ) :
				the_post();

				get_template_part( 'template-parts/content/content', 'page' );

				// If comments are open or we have at least one comment, load up the comment template.
				if ( comments_open() || get_comments_number() ) {
					comments_template();
				}

			endwhile; // End of the loop.
			?>

		</main><!-- #main -->
	</section><!-- #primary -->

<?php
get_footer();

Note the first thing is a call to get_header().

This includes the header.php file, also in the root directory, and this header file sets up the start of the page by including the entire head tag and then opens the body tag.

In your custom theme you do something very different, using only the index.php file (ignoring the built-in template hierarchy) which has the head tag built in. You include a header.php template, but this is simply the visual header on the page.

By breaking with the standard WordPress template hierarchy it will be very confusing for anyone working with your theme, and you risk creating compatibility issues.

In the case of Toolset's custom WordPress archives these depend upon the get_header action (triggered by the get_header call) which is pretty-much universally observed by all themes.

I'd recommend reviewing the official theme guide's advice on template files: https://developer.wordpress.org/themes/basics/template-files/

And note that, since WP 3.0, the ability to create theme's without separate (true) header.php and footer.php template files is deprecated.

#1456661

Hi Nigel,

Thank you for your in-depth reply which helped us to isolate and resolve the issue.

The way in which the template hierarchy is arranged is to provide maximum flexibility. WordPress SHOULD utilize searching inside sub-folders without issues as long as (1) its specified within the call, and (2) as long as the get_template_part() function is called. When we switch to get_header() and get_footer() that becomes an issue because those functions do not allow any parameters and only search within the root, unfortunately. (I will be entering a suggestion on their forums for that!)

Per your feedback and after researching and confirming the issue, we considered restructuring our framework to allow the header.php and footer.php files to be outside the html directory within the root. But, after researching the issue and reading some opinion posts within StackOverflow/Wordpress, it seems that the get_header() and get_footer() are not so commonly used, and therefore adding <?php do_action( 'get_header' );?> and <?php do_action( 'get_footer' );?> would allow the existing template hierarchy with get_template_part() to be used while facilitating the needs of those hooks firing.

Using either of these solutions (switching to get_header/footer or adding the php tags to the files) resolves the issue and got the framework to play nice with Types/Views and hypothetically other plugins that utilize get_header() and get_footer().

A pretty good trade-off if you ask me! 🙂 Once I've done that the portfolio page mentioned started loading accurately with the custom archive I created so I can continue building that out.

Thank you again for all the help and support. It is so refreshing to not just receive "This is a template issue. Try switching to Twenty Twelve." which so many support teams would leave it at that. Again thank you!

I am split 50/50 on if I should leave the action tag or if I should move the header/footer out of the html folder. My concern in doing so is if it will snowball into more files needing special circumstances while we are trying to provide a dead-simple file structure with our framework! Alas I have babbled enough. Thank you again for all you help!