In a few code snippets I may have to trigger a 404 error which I do with the following code.
// error 404 is displayed
global $wp_query;
$wp_query->set_404();
status_header(404);
The thing I notice is that WordPress just shows the standard " Whoops, that page is gone" 404 page instead of the Bricks Error Page template I have all setup.
The Bricks Error template page works fine for missing pages when typed in the browser URL but not when a 404 error is set via code in PHP.
How would I update the above code to set a 404 error and have the Bricks 404 Error Page show?
Any ideas⊠Looking at the bricks code I see that the issue actually starts in the Bricks 404.php file.
The get_bricks_data function cannot retrieve the Bricks Custom Error Page⊠it seems to not be able to find the error template id⊠or in reality Database::get_template_data cannot when it searches the active templates array⊠so it just displays the default echo statements found in 404.php file
I can retrieve the page manually if I for example specify the right post id for the error template in the 404.php file like so:
but the css styles are not included when the php file is returned.
Always mine is not the appropriate solution and I was just trying to debug and figure out what is going on.
Since you are much more familiar with the code base and how it all works can you see a solution to this problem so the Bricks database function is able to find and return the error page in this situation?
I am using WPCodeBox 2 to insert the snippet after the plugins are loaded. Iâve tried other hook points but it doesnât seem to matter the Bricks 404.php doesnât return the custom template.
On some sites I generate 404 errors for Author pages, Date Archives, Uncategorized Category etc⊠Stuff that is not needed for the site and shouldnât be accessible. Google advises that soft redirects to the home page, etc. shouldnât be used in these situations as they should be a 404.
@aslotta So i was following the calls in the Bricks code from 404.php for this issue and figured out that for some 404 errors the $active_templates array gets reused which causes some problems in this case.
To fix this in database.php in the function get_template_data() adding the array setup function:
self::set_active_templates();
and then in the set_active_templates() function itself commenting out the âCheck if set_active_templates already ranâ code.
These changes fix the issue but obviously with my limited knowledge of how the code in Bricks works a better solution can be found that doesnât require recreating the $active_templates every time the function get_template_data() is run. I did try to just recreate the array if the $content_type = âerrorâ but it only partially worked. This is something you guys can handle better with your indepth knowledge of the code base but hopefully I have pointed you in the right direction so the issue can get fixed.
can you maybe show âa working exampleâ using a different theme? Wanna make sure that itâs really Bricks that is behaving differently in this situation.
I tested it on another site with Elementor and its 404 error template is displayed. For example I usually disable access to the uncategorized Category taxonomy in WordPress if I do not use posts with the following code snippet.
<?php
// For example: https://domain.com/category/uncategorized/
// If not using Category Taxonomy deleting of Uncategorized Category not possible
function ess_disable_uncategorized_category_archives() {
// if we are on Uncategorized category archive page
if (is_category('uncategorized')) {
global $wp_query;
$wp_query->set_404();
status_header(404);
}
}
// Disable access
add_action( 'template_redirect', 'ess_disable_uncategorized_category_archives' );
This snippet when using Elementor and their Hello theme will return the 404 error template that I created.
This same snippet in Bricks does not return my custom 404 template.
I also disable the Author archive using a similar code snippet. It also has the same problem in Bricks but not with Elementor.
Same issue here, one year later. This is a massive bug that means we canât send people to 404 using PHP, which is quite a usual thing.
Any updates?
Works on every other theme I tested it with.
I used a more complex code snippet in the video, but itâs the same if I try to send a normal permalink to 404. I also didnât use a child theme, as this is for demonstration only. Itâs from wetransfer, so it wonât be online for long: https://we.tl/t-WnaMdF4wGr.
Thanks @Tom! Both Bugs are marked as solved, which they sadly arenât.
The code snippet works for me, but only if I send the user to 404 via PHP. If I f.ex. use a WP page that throws 404 I canât implement it. Take that /wp-sitemap.xml as an example (discourage index set).