I was able to upload a live, working website that has no reported errors. It was immediately clear that Local didn’t like the theme (Thesis 2.85) custom.php file. I was able to view and access the site only after I switched themes to WP-2019.
Then, while the site was accessible, I switched to the Thesis theme and Local went blank-page and reported a php error on a line number that exceeded the actual number of lines of the file… when I edited the file, the line number with the reported error moved in the correct direction, but still exceeded the number of lines in the file.
The file has no errors in DreamWeaver… The same when the code is tested at php code checker ( https://phpcodechecker.com/ ).
Right now, the only way for me to keep the Site and Admin opening in Local is to disable custom.php. But, when I do so, I can’t move from page to page… or do much else. It’s pretty useless.
Here’s the link to the actual live site, a copy of which is on Local:
By default Local reports more errors than most other server environments so that you are able to see small errors and warnings before they become a big issue.
The first thing I would check is if there is a different version of PHP on the live site as opposed to the Local one.
If you can, make the Local site use the same version as the remote site by creating the Local site with a Custom environment.
The next thing to take a look at is if the WordPress versions are different. Downgrading Local’s version of WordPress takes a little work, but can be done quickly through the terminal.
To do this:
Right click on the site and select “Open Site SSH”
In the terminal that opens execute this command:
wp core update --version='5.0' --force
You can replace the 5.0 with whatever version of WordPress you need to match the remote site. Let me know if matching the versions of PHP and WordPress helps in getting the site running on Local!
Thanks for replying. Yes, my Local is set as a Custom environment (1.3.2), with Apache.
The php versions are the same: 7.2.18 on the hosting server and 7.2 on Local
The WP version is the same for both: 5.2.1 – I downloaded the entire WP setup when I set Local.
As I said, I don’t get any reported errors elsewhere, smaller or larger. So I’m not sure what’s tripping Local or, more importantly, how to detect it so I could try to fix the problem.
Is there a point in posting the php file so you can see it has no errors?
Since the actual file doesn’t have any errors, it likely means that something isn’t being loaded correctly within the Local environment.
Can you provide a zip of the “logs” folder under the site’s folder? You should see “logs” next to “app”. This should give some more detailed info about what errors are being logged on the Local site.
Upon reviewing the logs, I’m seeing the following:
logs\php\7/2/0 reports the following, which is consistent with error messages I received when installing or attempting to run the site on Local with the custom.php loading (it is now renamed so not running):
unexpected end of file in /app/public/wp-content/thesis/skins/pearsonified/custom.php on line 99
As I mentioned, when reviewing the custom.php file in Dreamweaver (Adobe suite 5.0), no errors are reported.
Here’s the code of the customs.php file, in case you’d like to suggest adding an end section that would correct the “unexpected end of file” error that Local (and only Local) is generating.
Thank you again,
Jordan
=========
<?php
/* IOA WEBSITE */
/*
This file is for Skin-specific customizations. Do not change your Skin’s skin.php file,
as that will be upgraded in the future and your work will be lost.
If you are comfortable with PHP, you can make more powerful customizations by using the
Thesis Box system to create elements you can interact with in the Thesis HTML Editor.
For more information, please visit: http://diythemes.com/thesis/rtfm/api/box/
*/
/* Remove WP Emoji support scripts from Headers */
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
/*Changes having to do with moving Menu below header*/
global $thesis;
remove_action('hook_before_columns', array($thesis->skin, 'show_featured_item'));
add_action('hook_after_header', array($thesis->skin, 'show_featured_item'));
/*Make header image clickable*/
add_filter('thesis_pearsonified_link_header_image', '__return_true');
/* IOA STATUS BOX: HOMEPAGE (ARCHIVE), ABOVE EXCERPTS */
function ioa_status (){
if (is_home() ) {
?>
<div id="ioa_status_box">
<p><font color="#C60202"><em>IOA</em></font> content is updated on <a href="https://www.facebook.com/Israeli.Occupation" target="_blank">Facebook</a> and, rarely, <a href="https://www.twitter.com/IsOccupation" target="_blank">Twitter</a>.</p>
<p>**** ON THE <a href="http://www.israeli-occupation.org/about/status/">CURRENT STATUS</a> OF THE <font color="#C60202"><em>IOA</em></font> ****</p>
</div>
<?php }
}
add_action ('hook_top_content', 'ioa_status');
/* End of IOA STATUS BOX */
/*PAGE NUMBERING */
/*from ThemeBig.com -- www.themebig.com/317/new-and-improved-thesis-numbered-page-navigation/ */
function numbered_page_nav($prelabel = '', $nxtlabel = '', $pages_to_show = 6) {
global $wp_query, $paged;
$custom_range = round( $pages_to_show/2 );
$max_page = $wp_query->max_num_pages;
if( is_home() || is_archive() || is_search() || is_tax() ) {
if(!$paged) {
$paged = 1;
}
if($max_page > 1) { ?>
<ul class="numbered_nav"><li class="intro">Page <? echo $paged; ?> of <? echo $max_page; ?></li>
<? if( $paged >= ( $pages_to_show-2) ) { ?>
<li class="number"><a href="<? echo get_pagenum_link(); ?>">1</a></li><li class="ellipsis">...</li>
<? }
for( $i = $paged - $custom_range; $i <= $paged + $custom_range; $i++ ) {
if( $i >= 1 && $i <= $max_page ) {
if( $i == $paged ) { ?>
<li class="current_number"><? echo $i; ?></li>
<? }
else { ?>
<li class="number"><a href="<? echo get_pagenum_link($i); ?>"><? echo $i; ?></a></li>
<? }
}
}
if ( ($paged + $custom_range) < ($max_page) ) { ?>
<li class="ellipsis">...</li><li class="number"><a href="<? echo get_pagenum_link($max_page); ?>"><? echo $max_page; ?></a></li>
<? } ?>
</ul>
<? }
}
}
add_action('hook_bottom_content', 'numbered_page_nav');
/* PAGE NUMBERING ENDS */
/* BOTTOM NAVBAR */
function bottomNav_menu() {
?>
<div id="bottomNav_menu">
<ul id="bottomNav">
<li><a href="http://www.israeli-occupation.org/">Home</a></li>
<li><a href="http://www.israeli-occupation.org/about/about-us/" title="About the IOA">About the IOA</a></li>
<li><a href="http://www.israeli-occupation.org/about/contact-us/" title="Contact the IOA">Contact</a></li>
<li><a href="http://www.israeli-occupation.org/fair-use/">Fair Use</a></li>
<li class="noborder"><a href="http://www.israeli-occupation.org/discounted-haaretz-subscription-for-ioa-readers/">Haaretz Subscription Discount</a></li>
</ul>
</div>
<?php
}
add_action('hook_top_footer', 'bottomNav_menu');
/* BOTTOM NAVBAR ENDS */
?>
I understand the nature of the error message – but that is about as much as I understand PHP…
I actually did try to make small adjustments in the code, but it didn’t result in any change. And, as I mentioned, no other programs or servers indicated there was a problem with the code – the actual website has been running with this code for several years.
I thought you said earlier that you might be able to understand why this is happening after viewing the logs.
I exhausted my knowledge, and available resources, on this. If you think
you, or someone at Flywheel, can solve this, I’d be delighted to have it run locally. If not, it would be time to declare victory and move on.
Without seeing the entire site, it’s hard to know where things are failing. I think you’re pretty much left with trying to deactivate plugins until the issue disappears. You can always try installing this theme on a plain WordPress site and seeing if the issue persists.
This is likely something that doesn’t have to do with the custom.php file in particular, and is instead due to something that this file is doing to pull in other files.
Thanks again for your reply. I just disabled all plugins and the same behavior continued: when custom.php file is included in the setup, there’s a reported error (on line 100).
As to changing themes to plain WP, I tried it a while back and the site works well then… but, it is no longer the site I need to store.
My hunch is that is is in the custom.php file itself. Would you be able to pass this on to someone at Flywheel to see if they can spot the problem in the file?
As I mentioned before, it’s likely not something in this specific file, rather it’s something that is being included or referenced from somewhere else and is only bubbling up in this file.
Trying to debug this issue without a full working site to explore is pretty difficult.
Since this site doesn’t appear to be on Flywheel’s servers, you’ll need to reach out to a WordPress developer to take a closer look. They’ll likely need full access to the site in order to fully debug the issue.
Yes, I know you mentioned it wasn’t in this specific file… But you made a specific reference to plugins… and I followed up and disabled them all, and it did not resolve the problem.
And, when I disable this one file, the problem goes away. Unfortunately, so do the several functions this file controls (menus, page numbering code, etc.)
However, to clarify an important point: this is not a WP problem. The very same site (with additional plugins) is online and functioning perfectly. The problem flagged by Local (whatever is its source or nature) isn’t flagged by my server, or PHP editor and code checkers: it is a Local problem.
I am going to test removing elements of the PHP code in the custom.php file to see if this resolves the problem. If it does not, and if you’re unable to offer additional help, or elevate this to someone at Flywheel who could, I am going to have to move on and seek solutions elsewhere.
But I must say that I’m puzzled by all of this. This site – which is simple and straight forward – has been in continuous operation for 12 years, and in its current configuration (theme, plugins, etc.) for six years or more. It’s been running flawlessly, and had none of these problems I’m experiencing on Local. None. Not one. Just FYI.
Thank you, again: I really appreciate your trying to help!
Jordan
I went over the code in custom.php. I was able to isolate the offending code: it’s the archive page-numbering system. Everything is OK, except for the following:
If you, or someone else at Flywheel, have any suggestions on how to make it work, I’d greatly appreciate them. Similarly, if you know of an alternate code that would do the same, that would be most helpful.
So, I’m glad to report that the site can work on Local in every other respect.