justinmaurerdotdev

Okay, you know what. Updating the CMB2 code to the newest version seems to have solved my issue. I’m going to RE-mark this as “resolved”. If anyone else has this problem, update CMB2.

Hi Michael,
It’s been a while since I looked at this issue, obviously, but it is still bugging me, and now I have time to fix it.

The fields in question are a phone number (text) field and a profile image (file upload) field. Every time I go use this page, the very first phone number/file path I ever entered into the field is automatically populated. I’m assuming I shouldn’t need to set an empty string as the default here.

I THINK I’m having the same issue (where it’s bringing up an old value rather than the actual default) with a couple of select fields as well, but it’s hard to tell if it’s the same problem.

Is there any way to clear these values from the memory of these fields? Why could this be happening?

Thanks in advance for any help on this!

I think I may have a solution here, but I’d still like some input.

I can’t say I completely understand why some templates are behaving differently from others, but here’s what I’ve figured out.
When using a custom template (assigned on the Page editing screen), WordPress generates a body class in this format: page-template-{directory}{filename}-php. Our styling is based on this format: page-template-{filename}-php. All of our page templates are stored within a /pages directory, so the class generated doesn’t match the class we’ve used for styling (BUT ONLY ON 2 PAGES?!). On all other pages, WP seems to be generating the wrong classes based on our file structure (page-template-{filename}-php w/o the directory name)
So, I see two possible solutions.
1) Move all templates (or at least the offending ones) from /pages/ to the root folder of the theme. Each template will need to be reassigned on the page edit screen.
2) Add the correct classes to all css for the current setup. So, where ‘.page-template-my-template-php’ appears, we would add ‘.page-template-pagesmy-template-php’ (and ideally add that format for every other page-template class).

Like I said, I’m still trying to wrap my head around why some of them behave one way and others behave another way, but I’m almost positive the above fix will solve our issue. I like option 1 better, as it doesn’t require code changes, just a file structure change and some WP admin work.

Any thoughts about why this behavior seems inconsistent in WordPress?

Solved this. I just needed to scrap the plugin and use the following code in my htaccess…AND switch my site/home URL to https://. But, now we’re all good.

Here’s what I used, in case anyone else has this issue:

# BEGIN HTTPS REDIRECT
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</IfModule>
# END HTTPS REDIRECT

Okay, I’ve solved it. I finally found this ticket where someone had the same problem. Ideally, you would is is_front_page() to handle the home page separately, but is_front_page() doesn’t work with the pre_get_posts hook. Instead, we can use this to get around that conditional:
if ( $query->get('page_id') == get_option('page_on_front') )

So, my code ended up being this:

if ( $query->is_main_query() && !is_admin() && is_page() ) {
		if ($query->get('page_id') == get_option('page_on_front')){
			$id = get_option('page_on_front');
		} else {
			$id = get_queried_object_id();
		}
		if( $sitechild = site_child($id) ) {
			$query->query_vars['page_id'] = $sitechild;
		}
	}

Marking as resolved. Just wanted to leave this there in case anyone else is struggling with this like I was.

Okay cool. Good to know. Thanks for clearing that up. Marking as resolved.