Create WordPress themes with beautiful OOP code and the Twig Template Engine

Tickets: #1219, #1793.

@pascalknecht and I thought about what would be the most consistent way to go forward with Object Factories and the changes that come to the API. Here’s our proposal. As discussed in #1219, we’re starting with the documentation first.

How to navigate this proposal

1. Read the new documentation for Posts, Terms, Class Maps and the updated documentation for the Context (see commit for changes).
2. Read the updates to the Upgrade Guide (see commit for changes).
3. Continue reading this pull request.

The API

We’ve found that the new API could evolve around Class Maps. Class Maps define what objects will be used for getting single objects as well as collections of objects. We already have them in Timber, but we don’t use them in all the places yet.

When we only have Class Maps, we can use them as a central hub to set what classes are used in Timber. A single source of truth, so to say. We could remove the existing possibilities that we currently have in certain functions to pass in the class that should be used, like for Timber::get_posts() and Timber\PostQuery().

@aj-dl proposed to always be explicit when instantiating new posts in https://github.com/timber/timber/pull/1219#issuecomment-503400807. We think that is a good idea in general, at least better than always getting something from a Post class, which then might not necessarily be a Post, but a child class of Post.

However, by being explicit, we could only be explicit with objects that can be instantiated directly. But for all other functionality like $post->thumbnail() where the instantiation is hidden in a function, we would still have to rely on the Class Map. It still wouldn’t be clear when exactly the classes we defined in the Class Map would be used.

I myself have recently found that when I had to define the class that should be used in several places, I ran into a couple of cases where I was confused why something didn’t work, until I realized that I didn’t pass the class to be used in a function parameter. If we’d have Class Maps only, we wouldn’t have to think about instantiating objects with the proper class all the time.

Because of @aj-dl’s comments, we explored the different options we had for the API and thought about the following possibilities:

• PostFactory::get() and PostQueryFactory::get() – Like I commented in other issues before, I would find it great if we wouldn’t introduce the concept of factories into the API, but keep it hidden behind the scenes. Developers should be able to start with Timber without having to understand the concept of factories.
• Post::get() and PostQuery::get() – Here we would clearly state what we get, but there could be confusion about the naming. And we would probably have to rename the Timber\Post class to something like Timber\BasePost and make get() the only method in Post.
• Timber::post() or Timber::posts() – Here it might not be clear enough that you get something. It could also be understood as posting something.

Which leads us to the proposed API. We think we should use the functions we already have:

• Timber::get_post()
• Timber::get_posts()
• Timber::get_term()
• Timber::get_terms()

This is basically what @acobster already proposed in https://github.com/timber/timber/pull/1219#issuecomment-435624322. All of these functions could rely on Class Maps. The benefits of this API would be:

• 👍 Developers can mostly use the API they already know. It’s really close to how WordPress works. We will make usage stricter though, with some deprecations.
• 👍 By using Class Maps, you define what custom classes are used and when in a single place. If you want to use a new method in Twig and extend Timber with a new class, you only need to update the Class Map and update your Twig file, but not every instantiation of where you need to use that class.
• 👍 By defining all public functions in the Timber class, developers get a nice overview of the API when looking at the code or the online documentation.
• 👍 Automatic template contexts become even easier. There’s no need to manually call setup() when using a custom class, because the context also uses a Class Map.

The drawbacks:

• 😔 With Class Maps, you don’t see right in the code what class you’re dealing with and you can’t make use of navigating to that class in your IDE. Syntax highlighting might not work properly without adding custom DocBlocks with @var definitions.

Do you see any other benefits or drawbacks? We’d be pleased to hear them.

Factories

For the factories implementation, I think we’re still on track in https://github.com/timber/timber/pull/1793 and can continue discussing and working out the details about the factories themselves there.

This pull request can be used for the changes to the documentation (without documentation in DocBlocks).

Proposed Changes

When we stay with the proposed API, we can target to release Timber 2.0 sooner, because the only thing that’s holding us back is how the public API will look like. There are changes that need to be made for 2.0 and then there are changes that we can make later, in 2.x.

Changes for 2.0

For 2.0, we could implement updates to the API for post objects only.

• [x] Add option to use callback functions in Class Maps. #2093
• [x] Add Class Maps for Terms, Users and Comments. #2093
• [x] Always use an array instead of a string as the default argument passed to the timber/post/classmap filter. #2093
• [x] Deprecate Update the API to prohibit passing in the class to use for instantation in all post functions and use the Post Class Map as the single source of truth. #2090
• [x] Deprecate Update the API to prohibit passing in query strings to Timber::get_posts(), like here: Timber::get_posts( 'post_type=article' ); #2090
• [x] Deprecate Update the API to prohibit passing in the class to use for instantation in all functions and use the new Class Maps as the single source of truth. #2090
• [x] Implement Timber::get_menu(), Timber::get_user(), and Timber::get_comment() methods. #2089, #2197
• [x] Replace all direct instantiations in core and tests with the corresponding Timber::get_* calls. #2094
• [x] Throw a doing-it-wrong exception when a Post [Term, Menu, Comment or User ] or PostQuery object is instantiated directly. (Is that even possible?) Make Post, Term, Comment, and User constructors protected. #2088 ( Menu and MenuItem constructors will be made protected in #2292)
• [x] Add to_array() to Collection classes so that we can use something like Timber::get_posts( $query )->to_array().
• [x] Add a new User Guide.
• [x] Deprecate Timber\PostClassMap filter and rename it to timber/post/classmap. Currently, it’s called timber/post/post_class in the 2.x branch. #2293
• [ ] Determine what happens when a timber/*/classmap filter callback returns something other than a CoreInterface. (Probably should throw an exception rather than just letting it TypeError.) - also #2293
• [ ] Finalize type declarations #1863
• [ ] Implement the new PagesMenu API. #2292
• [x] Implement ::get_image() and ::get_attachment() top-level methods and corresponding Twig functions. #2333

Backwards compatibility

With the proposed API, we would replace the existing API for Timber::get_post() and Timber::get_posts(). We will have to consider what happens with the differences between get_posts() and WP_Query as discussed in https://github.com/timber/timber/issues/1957.

Open Questions/Discussion

@jarednova, @pascalknecht, @acobster, @palmiak, @aj-adl: I’d be happy to get your opinions on this pull request. Some more questions came up while working on this pull request:

• ~~I know Inheritance is not always the best option for Object Oriented Programming. Does anybody see any problems with class conflicts?~~
• ~~Are callback functions in the Class Maps enough to have advanced control over what class is used when?~~
• For the API in Twig, we still have Post, PostQuery, etc. For consistency, should we consider renaming these functions to get_post(), get_posts(), etc?
• ~~Should we use Timber::get_posts() or Timber::query_posts()? Would it be more clear that query_posts() returns a query/collection of posts, and not an array of posts?~~

Todo

• [x] Update Context Guide with new function signatures.
• [x] Document no_found_rows, see https://github.com/timber/timber/pull/2073#issuecomment-535720949. → Documented in https://github.com/timber/timber/blob/2.x-docs-api/docs/v2/guides/posts.md#count-rows-only-if-needed
• [x] Document Timber::get_posts( $query )->to_array(), see https://github.com/timber/timber/pull/2073#issuecomment-571375271.
• [x] Document difference between post arrays and PostCollections. → Documented in https://github.com/timber/timber/pull/2073/commits/508aa9efee730798288592a7d67becec20b84c0d
• [x] Optimize API for Menu Class Maps #2247.
• [x] Document JSON serialization of posts #2311. (#2335)
• [x] Update Upgrade Guide with updates added in #2311. Done in https://github.com/timber/timber/pull/2073/commits/82b6a6abb40f614e6821714f10b82d75042a6185.
• [x] Update Upgrade Guide with changes from THE PURGE in #2354, including the removal of the timber/get_posts/mirror_wp_get_posts filter. Done in #2367.

I've been using Timber with Bedrock.

Until RC3, there were no major issues. Now Timber calls is_admin() and uses WordPress hooks on being loaded. Because Bedrock loads Composer dependencies before WordPress this will cause a fatal error.

Is the only solution to switch to the plugin version of Timber?

Hi there,

Happy new year to the Timber team!

Issue

ACF and Timber have different ways of representing some common values like image, dates, etc.

For example, native WordPress images (e.g. post thumbnails) are Timber\Image objects whereas ACF images are arrays. More importantly, they don't share the same keys for holding the same values (url ≠ src, mime_type ≠ post_mime_type, etc.).

I find this a bit annoying and confusing to switch between those two representations. It can also be error prone.

Solution

Convert fields that can be converted (like Timber does for post objects) to Timber/standard objects and have a unified API when working with data in templates.

I'm thinking about those fields:

• image -> Timber\Image
• gallery -> array of Timber\Image
• date picker -> DateTime object
• date time picker -> DateTime object

I'm already using it in my own projects and I think it would be great if those features were implemented in Timber core.

Impact

This will cause some breaking changes because {{ post.meta('my_key') }} will not return the same values anymore but hey, that's what major version are made for 😁

I chose to not honor the "return format" value in ACF which is almost (not to say always) useless, at least to me. Let me know if you see some use case where it could be legitimately used. This is a draft opened for discussion.

Usage Changes

Most notable changes:

• no "return format" anymore, images fields will always return Timber\Image, dates will always return DateTime objects, etc.
• key/values changes

Considerations

Nothing comes to mind.

Testing

This PR only contains image test right now as it's a draft.

Work in progress final port of the Posts API to use Factories under the hood.

• [x] Switch ::get_post[s]() API to use Factories
• [x] Replace a bunch of direct instantiations in the tests
• [x] Fix Term::posts()
• [x] Post::build() method
• [x] Attachment/Image class map callback
• [x] Update Twig functions (@gchtr doing on #2178)
• [x] Simplify PostQuery::__construct() to only accepting a WP_Query instance (with no wrapping it in an array)
• [x] Fix #2178 and merge in to this feature branch
• [x] Make Post::__construct() protected, annotate WP_Post arg
• [x] Timber::get_attachment_by()
• [x] Close the loop on whether we need to pass an array as a second arg to wp_check_filetype()
• [x] Attachment::__construct() has an option to pass an array like ['ID' => 123] ~...are we good to drop support for this? Otherwise we would need to handle this special case in ::get_post().~ we need to support this for ACF integration, so add a special case for this in ::get_post() (or PostFactory?)
• [x] @expectedIncorrectUsage is failing randomly on those two tests...y tho.
• [x] deprecate Attachment::get_pathinfo() and Image::get_pathinfo() and use Attachment::pathinfo() only to be in line with other post method names.
• [x] Support the merge_default option in ::get_post[s]()

When calling get_src (either directly or through typecasting a TimberImage instance to a string), the method doesn't take into account any of the standard WP methods for retrieving the image's URL (e.g. wp_get_attachment_url or wp_get_attachement_image_src) and instead goes off and does it's own thing for deriving the URL.

This works fine in what I would expect to be the majority of use-cases, however where other plugins are used to modify the location of files (in my case, moving uploaded files to an S3 bucket and then removing them from the server), this no longer works.

I suppose this is partially an issue with the other plugin, however they correctly apply a filter to the result of the above core method calls that would otherwise allow it to play nicely with other plugins. i.e. Calling wp_get_attachment_url($id) shows the Amazon S3 URL, not the (incorrect) location on the server.

Is there a reason why you went with a custom implementation over using a core method?

As a workaround for my case (and would work for anyone else affected by this issue), I just sub-classed TimberImage and overrode the get_src method:

<?php

namespace MyProject\PostType;


class Image extends \TimberImage {
    /**
     * @var int
     */
    private $iid;

    /**
     * @param int $iid
     */
    public function __construct($iid) {
        $this->iid = $iid;

        parent::__construct($iid);
    }

    /**
     * @param string|array $size - See http://codex.wordpress.org/Function_Reference/wp_get_attachment_image_src
     * @return array|bool|string
     */
    public function get_src($size = 'full') {
        return wp_get_attachment_image_src($this->iid, $size)[0];
    }
} 

I'm happy to put a PR up to correct this, but as I don't fully understand the reasoning behind the current implementation I'm reluctant to do so without hearing from you first.

Thanks (and thanks for the library, it's awesome!) :)

Issue

When looking into timber for a project I'm currently working on, I was looking to make use of path namespaces (e.g. https://symfony.com/doc/current/templating/namespaced_paths.html#registering-your-own-namespaces) but it seems that Timber doesn't currently support this.

Solution

This patch introduces support for path namespace, at time of writing only as part of user defined locations, however this could easily be added to to support namespace in theme dirs as well if you wanted.

Impact

It should be backwards compatible, so it shouldn't have any negative impact on existing users.

Update This will have an affect on users of some filters, see https://github.com/timber/timber/pull/1791#issuecomment-423122266

Usage Changes

Users who wish to make use of path namespaces can now do so, e.g. with a styleguide namespace

Timber::$locations = array(
    '/Users/jared/Sandbox/templates',
    '~/Sites/timber-templates/',
    ABSPATH.'/wp-content/templates',
    ABSPATCH.'/wp-content/styleguide' => 'styleguide'
);

Considerations

I've not spent too much time on this patch, I'm hoping for some guidance/advice if there are any edge cases I may not have considered as I am very new to this library.

~It's also worth noting that I've just checked for a namespace presence and ignored if none there, but we could easily change to give each location the default namespace (__MAIN__) if none is configured, to cut down on an if statement.~

Update This now does indeed set the default namespace.

Testing

~I included one basic unit test, but would be happy to add more if you think this patch is worth including.~

Update Have included several useful tests.

Expected behavior

Resize filter should return new path I'm experiencing a similar issue to #237. Resize filter was working, but now it is not. The image is still being created (it is in the content/uploads directory), but the original upload URL is being included instead. Oddly, it is working just fine on my staging site and local server with the same codebase and Timber / WP versions. I've had this happen recently with another site too, but the error occurred on the staging site rather than production.

I noticed the issue after upgrading to Timber 1.2.1, but I am using the same version of Timber across all of my installs and not experiencing the problem everywhere.

Questions from Issue #237:

Are you running WP from a subdirectory?

No

Do you have "normal" setup with /wp-content/uploads/ etc.?

Yes

Do all images fail?

Yes

Actual behavior

Resize filter creating cropped image but not returning the path

Steps to reproduce behavior

{% for accessory in post.get_field('featured_accessory') %}
  <img alt=""
    src="{{ TimberImage(accessory.image).src | resize(400, 266) }}"
    sizes="(max-width: 47.9375em) 100vw, (max-width: 59.9375em) 50vw, 33vw"
    srcset="{{ TimberImage(accessory.image).src | resize(400,266) }} 400w, {{ TimberImage(accessory.image).src | resize(750,500) }} 750w">
{% endfor %}

What version of WordPress, PHP and Timber are you using?

WordPress 4.7.1, Timber 1.2.1

How did you install Timber?

Upgraded to newest version via plugin updater in WordPress dashboard.

Hello, I have added the following to my functions.php:

Timber::add_route('blog/:name', function($params){
      $context = Timber::get_context();
      $args = 'category_name='.$params['name'];
      $posts = Timber::get_posts($args);
      $context['posts'] = $posts;
      Timber::render('index.twig', $context);
});

If I now call eg: localhost/blog/food It will display all Posts with the category food, but also the 404 Page content is shown.

What am I missing?

I also tried :

Timber::add_route('blog/:name', function($params){

    $query = $params['name'];
    Timber::load_template('index.php', $query);
});

but I get :

Strict Standards: Non-static method Timber::load_template() should not be called statically in /Applications/MAMP/htdocs/wordpress/wp-content/themes/timber-starter-theme/functions.php on line 57

Warning: array_keys() expects parameter 1 to be array, string given in /Applications/MAMP/htdocs/wordpress/wp-includes/class-wp.php on line 420

Warning: Cannot modify header information - headers already sent by (output started at /Applications/MAMP/htdocs/wordpress/wp-content/themes/timber-starter-theme/functions.php:57) in /Applications/MAMP/htdocs/wordpress/wp-includes/pluggable.php on line 875

I am new to Timber and I have inherited a site that is using Timber and Twig. I need to know if there is a way to overide or skip over the Timber system for one template. I have a very complicated custom template I need to create and I want to bypass the system for this one template. I have tried in both the functions, index file to check for if the template is being used to not load all of the Timber files but not having success.

Thanks in advanced for any help.

Expected behavior

I have a relationship field pulling in a repeater of images and expect them to display.

Actual behavior

If I print_r I only get the count of how many images there are printed. A dump returns:

string(1) "4"

I tried setting the repeater field to return Array, URL and ID on the image field and they all produce the same result. I know I've done this in past versions of Timber, so I'm wondering if something has shifted in how I need to get these field values?

Steps to reproduce behavior

PHP file:

$context['featured_case_studies'] = get_field('featured_case_studies');

Twig file:

{% for study in featured_case_studies %} {% set study = TimberPost(study) %} <div class="case-study-entry" id="study-0{{loop.index}}"> <div class="study-title"> <span>Case Study</span> <h4>{{study.title}}</h4> <h3 class="location">{{study.location}}</h3> <a href="" class="view-photos"><img src="{{site.theme.link}}/assets/img/view-photos.gif" alt=""></a> <div id="" class="project-photos"> {{ dump(study.project_photos) }} {% for photo in study.project_photos %} <a href="" rel="study-0{{loop.index}}" class="fancybox"><img src="{{TimberImage(photo.project_image).src|resize(1200,9999,'center')}}" alt=""></a> {% endfor %} </div> </div> </div> {% endfor %}

(Not sure why my code won't format properly, sorry for that. Spacing it out only made it worse).

What version of WordPress, PHP and Timber are you using?

WP 4.5.2 and Timber 10.0.1

How did you install Timber? (for example, from GitHub, Composer/Packagist, WP.org?)

Downloaded from wp.org

UPDATE

I did roll back Timber and got the same behavior.

Ticket: #869 Reviewer: @jarednova

Issue

Modernising Timber to use namespaces

Solution

A lot of code changes...

Impact

Is fully backwards compatible, I was thinking of using a trait, but as the list of classes that needed backwards compatibility is atomic, it was easier just to create a function.

Usage

Yes, too much to list here. See considerations.

Considerations

We need to update all the docs to represent this new change.

Testing

Tests need updating with this.

For now to test you can do the following composer require timber/timber:dev-dev-namespacing

After updating WP from 5.8.5 to 6.1.1 Timber::get_post and Timber::get_posts return null on posts, categories, and tags.

Expected behavior

return non empty WP_Query with actual post / taxonomy

Actual behavior

global $wp_query; also returns null

object(WP_Query)[7856]
  public 'query' => null
  ...

get_the_ID() return false or 0

Steps to reproduce behavior

just update WP from 5.8.5 to 6.1.1

What version of WordPress, PHP, and Timber are you using?

Example: WordPress 6.1.1, PHP 7.4, Timber 1.3.4

How did you install Timber? (for example, from GitHub, Composer/Packagist, WP.org?)

Timber installed as a lib inside the project

Issue

Setting public properties for user meta fields results in {{ user.first_name }} to return null. Because those properties are not WP_User properties and thus not imported.

Since those properties are declared, Twig will not retrieve them either: https://twig.symfony.com/doc/3.x/templates.html#variables

Solution

Remove public properties matching user meta so __call in Timber\Core is actually called.

Impact

None.

Usage Changes

You can now do {{ user.first_name }}, {{ user.last_name }}, etc.

Testing

Just changed the test with description to ensure this works fine.

Expected behavior

I want to display pagination under a list of posts on a custom page template. I'd expect to see the pagination based on the values in $context['posts']

Actual behavior

I don't get any pagination at all. The pagination.pages var is empty.

Steps to reproduce behavior

I used the following code, based on https://timber.github.io/docs/v2/guides/pagination/#what-if-im-not-using-the-default-query?

use Timber\Timber;
use Timber\Pagination;
if (!isset($paged) || !$paged) {
	$paged = 1;
}
$context = Timber::context();

$context['posts'] = Timber::get_posts( [
	'post_type' => 'post',
	'paged' => $paged,
] );

// Set pagination to show 2 pages before and 2 after the current selected page.
$context['pagination'] = Pagination::get_pagination( [
	'mid_size' => 2,
	'end_size' => 1,
	'show_all' => false,
] );

echo Timber::compile( [ 'partials/post-list/list.twig' ], $context );

It looks like the $wp_query var is not passed to the Pagination class which caused it to use the $wp_query of the current page, which (logically) has no pagination.

What version of WordPress, PHP and Timber are you using?

WordPress: 6.1.1 PHP: 7.4.21 TImber: 2.0.0-beta.1

How did you install Timber? (for example, from GitHub, Composer/Packagist, WP.org?)

Timber is installed via composer.

Hi, I am upgrading PHP on this website since we are using PHP 7.4, however, once I go to PHP 8.0+ I get a Fatal error and I see this on the error log:

PHP Fatal error:  Uncaught Error: Undefined constant "ENV" in /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Extension/CoreExtension.php:1661
Stack trace:
#0 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Extension/CoreExtension.php(1661): constant('ENV')
#1 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Environment.php(497) : eval()'d code(30): twig_constant('ENV')
#2 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(453): __TwigTemplate_53e9d8e1532f224322e40f11d9628ced0ef859351326ec40020691e39bf7212b->doDisplay(Array, Array)
#3 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(420): Twig\Template->displayWithErrorHandling(Array, Array)
#4 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Environment.php(497) : eval()'d code(84): Twig\Template->display(Array)
#5 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(453): __TwigTemplate_463bbf3a9ad038b5ee00f4f934eb82c973c950e04f16fdf7b490be87ad3d210b->doDisplay(Array, Array)
#6 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(420): Twig\Template->displayWithErrorHandling(Array, Array)
#7 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Environment.php(497) : eval()'d code(35): Twig\Template->display(Array, Array)
#8 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(453): __TwigTemplate_6117eef2967e4024a8ddd13d22f98637553697006029f77f64e8511beda77b5b->doDisplay(Array, Array)
#9 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(420): Twig\Template->displayWithErrorHandling(Array, Array)
#10 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Environment.php(497) : eval()'d code(31): Twig\Template->display(Array)
#11 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(453): __TwigTemplate_1412182097d0a23bc5f170f22c3537c40d9efcdedeb01625fc6e0e9929b2a5d5->doDisplay(Array, Array)
#12 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(420): Twig\Template->displayWithErrorHandling(Array, Array)
#13 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Template.php(432): Twig\Template->display(Array)
#14 /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/TemplateWrapper.php(47): Twig\Template->render(Array, Array)
#15 /dom42117/wp-content/plugins/timber-library/lib/Loader.php(79): Twig\TemplateWrapper->render(Array)
#16 /dom42117/wp-content/plugins/timber-library/lib/Timber.php(334): Timber\Loader->render('page.twig', Array, false, 'default')
#17 /dom42117/wp-content/plugins/timber-library/lib/Timber.php(383): Timber\Timber::compile(Array, Array, false, 'default', true)
#18 /dom42117/wp-content/plugins/timber-library/lib/Timber.php(410): Timber\Timber::fetch(Array, Array, false, 'default')
#19 /dom42117/wp-content/themes/accedian/page.php(70): Timber\Timber::render(Array, Array)
#20 /wordpress-versions/6.1.1/wp-includes/template-loader.php(106): include('/dom42117/wp-co...')
#21 /wordpress-versions/6.1.1/wp-blog-header.php(19): require_once('/wordpress-vers...')
#22 /wordpress-versions/6.1.1/index.php(17): require('/wordpress-vers...')
#23 {main}
  thrown in /dom42117/wp-content/plugins/timber-library/vendor/twig/twig/src/Extension/CoreExtension.php on line 1661

WordPress 6.1.1, PHP 8.0, Timber 1.22.1

Thanks!

I have a CPT that I'm filtering with custom query vars associated with ACF fields. Pagination pages lead to 404 whenever the meta_query is active. I've tried every possible solution I can find in the docs and on Stackoverflow. Any assistance would be appreciated.

On search.php:

if ( $post_type == 'funded_grants' ) {

  $program_type = get_query_var('program_type');
  $contributor = get_query_var('contributor');
  $researchers = get_query_var('researchers');
  $area_of_research = get_query_var('area_of_research');
  $disease_areas = get_query_var('disease_areas');
  $province = get_query_var('province');
  $start_date = get_query_var('start_date');
  $end_date = get_query_var('end_date');

  $meta_query = bc_create_meta_query();

  $args = [
    's' => $text_query,
    'meta_query' => $meta_query,
  ];

  $context['posts'] = new Timber\PostQuery($args);

  Timber::render(['archive-funded_grants.twig'], $context);

}

In functions.php

function filterFundedGrantsSearch($query) {
    if ($query->is_search && $query->get('post_type') == 'funded_grants' && !is_admin() ) {
      $query->set( 'posts_per_page', 5 );
      $query->set( 'paged', (get_query_var('paged')) ? get_query_var('paged') : 1 );
    }
    return $query;
  }

  add_filter('pre_get_posts','filterFundedGrantsSearch');

function bc_create_meta_query()
{
    $program_type = get_query_var('program_type');
    $contributor = get_query_var('contributor');
    $researchers = get_query_var('researchers');
    $area_of_research = get_query_var('area_of_research');
    $disease_areas = get_query_var('disease_areas');
    $province = get_query_var('province');
    $start_date = get_query_var('start_date');
    $end_date = get_query_var('end_date');

    $meta_query = array();

    if (isset($program_type) && $program_type > 0) {
        $meta_query[] = array(
            'key' => 'fg_program_type',
            'value' => array($program_type),
            'compare' => 'IN',
        );
    }

    if (isset($contributor) && $contributor == 'on') {
        $meta_query[] = array(
            'key' => 'fg_contributor',
            'value' =>  3500,
            'compare' => 'LIKE',
        );
    }

    if (isset($researchers) && $researchers > 0) {
        $meta_query[] = array(
            'relation' => 'OR',
            array(
                'key' => 'fg_principal_investigator',
                'value' =>  $researchers,
                'compare' => 'LIKE',
            ),
            array(
                'key' => 'fg_team_members',
                'value' => $researchers,
                'compare' => 'LIKE',
            )
        );
    }

    if (isset($disease_areas) && $disease_areas > 0) {
        $meta_query[] = array(
            'key' => 'fg_disease_areas',
            'value' => $disease_areas,
            'compare' => 'IN',
        );
    }

    if (isset($area_of_research) && $area_of_research > 0) {
        $meta_query[] = array(
            'key' => 'fg_area_of_research',
            'value' => array($area_of_research),
            'compare' => 'IN',
        );
    }

    if (isset($province) && $province > 0) {
        $meta_query[] = array(
            'key' => 'fg_province',
            'value' => array($province),
            'compare' => 'IN',
        );
    }

    if (isset($start_date) && $start_date > 1) {
        $meta_query[] = array(
            'key'     => 'fg_start_date',
            'value'   => $start_date,
            'compare' => '>=',
        );
    }

    if (isset($end_date) && $end_date > 1) {
        $meta_query[] = array(
            'key'     => 'fg_end_date',
            'value'   => $end_date,
            'compare' => '<=',
        );
    }

    if (count($meta_query) > 1) {
        array_unshift($meta_query, array('relation' => 'AND'));
    }

    return $meta_query;
}

Timber is installed with Composer. Wordpress 6.1.1. PHP 8.1.9.