Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
Regarding your first issue, could you emulate the problem using CSSDesk.com?
Thread Starter
mbdk
(@mbdk)
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
Would you be able to use the same HTML as per your page? The idea is to show us your webpage without putting it live. If you’re not comfortable with that, helping you with a CSS problem is going to be impossible.
Thread Starter
mbdk
(@mbdk)
Sure, I thought I published the necessary code but I updated the link above with the whole code from the View Source, but I anonymized as much as I could the URLs and the labels due to privacy reasons of the company (not mine).
Problem 1
This is discussed in the forum. Look to see where there are anchor elements with borders. In your child theme copy the elements with borders and make them 0 or invisible in some way (color:transparent; or the same as the background color) so they don’t appear.
Problem 2
Have you copied the directory structure exactly in your child? I wasn’t sure.
Have you cleared caches, etc.?
Just some thoughts from another newbie.
Thread Starter
mbdk
(@mbdk)
Problem 1: I have searched high and low (using ctrl+F) for anything with text-decoration: underline; or anything with borders that might affect this (using the Inspect Element to see which CSS properties affect my links), but I haven’t found any.
Problem 2: yes, the files have the exact same directory structure in the parent and child themes, and I have cleared the history, cache, etc.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
@mbdk, (1st issue) It’s box shadow. I recommend looking at a web developer toolbar like the one that comes in Chrome. Right click on a link and press “Inspect element”. A new toolbar appears and along the right hand panel you will see CSS that is applied to the link. You can un-tick that CSS to see whether it is affecting the link styling.
If you don’t want the underline but would still like it on hover, try this:
.entry-content a,
.entry-summary a,
.widget a,
.site-footer .widget-area a,
.posts-navigation a,
.widget_authors a strong {
-webkit-box-shadow: none;
box-shadow: none;
}
Thread Starter
mbdk
(@mbdk)
Thanks @anevins, that solved issue #1.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
Regarding the other issue, have you tried changing more things to see if that takes effect too? Like have you tried adding a random bit of text and seeing if it shows up on the webpage?
Thread Starter
mbdk
(@mbdk)
Yes, I have successfully changed other texts and added more things, but my problem is with the files in the OP. I have even tried deleting the files in the child theme and recreating them again from the parent theme.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
Yes, but to make sure those files in question are being read correctly, can you try adding “FOO” somewhere in the file (where it doesn’t cause a syntax error) and see it it’s being output on the page? To check if the file is being loaded at all?
Thread Starter
mbdk
(@mbdk)
I just did and the new words I added are not being displayed.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
I’m afraid I don’t know the answer, but I think the next step would be to look how the theme loads these files. Once we understand that we may understand why it’s not loading your Child Theme.
The inc/template-tags.php file is a separate issue from template-parts files. The functions in this file are pluggable functions. You can redeclare these functions on any valid PHP page. The child’s functions.php would be fine, as would a separate template-tags.php file. If you use a file separate from functions.php, you need to reference it with a require_once statement on the functions.php file. The child template overwriting system does not apply to regular PHP code files such as this. You need to manage the references yourself. You only need to redeclare functions you wish to change, you don’t necessarily need the entire file content. Include the if (!function_exists()): endif; bit as well even though there will not be further overrides. It prevents warnings during theme activation.
The template-parts files are of course part of the theme template system. As long as the parent is using the get_template_part() function to load template parts, any child template parts that exist will be used in preference over the parent’s files. This is the case with twentyseventeen, so your child files should be utilized. Be sure you utilize the same relative paths and filenames as the parent does. Verify that WP has proper permissions to access these files.
What happens when a template calls get_template_part() is WP first checks if any child files exist in the specified path relative to the theme folder. WP uses file_exists() for this, so if it returns false due to a permissions issue or because no such file actually exists, it tries to get the template from the parent path. This should always be successful, but by chance the parent file does not exist, the file is searched for in the internal default theme. If that fails, nothing happens. WP uses the first valid file found in that sequence, so child files always take precedence if they exist.
I’ve tested this on my own twentyseventeen child and template-part files are definitely used where they exist. There are no filters in the template part loading code, so plugins cannot alter this behavior. The only way to change behavior is through a dirty hack of altering core files. The only other explanation for why child files are ignored is some server configuration is preventing WP from seeing that such files exist.
Be sure the original twentyseveteen files have not been altered, as well as wp-includes/template.php and general-template.php core files. You might consider replacing the files from a fresh download of the exact same version to be sure. Be sure no caching is in place that prevents you from seeing changes to child files. There could be general server caching placed by your host that is outside of the WP environment. If so, there should be a way of flushing the cache from cPanel or something.
In summary, there are 4 possible explanations why child templates fail to load:
1. errors in child path/file names
2. altered theme or core code
3. server configuration or file permission issues
4. caching in place, either within or external to WP
Thread Starter
mbdk
(@mbdk)
Thanks @anevins and @bcworkz. I have reinstalled the theme in a different directory and server, checked file permissions for the folders and server config, and recreated the child theme from the very beginning. The only file that is not reacting to changing that one word is template-tags.php. I don’t think there’s much more I can do, so for now I’ll consider this finished.
