JohnHenryUS

Hunt -n- peck: adding “+1” to the year on line 214 of widget.php fixes the “no display for this year’s posts” problem:

        $date_query = array(array('before' => array('year' => wp_date('Y') + 1)));

Hate edit timeouts on this forum ?? So an update for the Blubrry Powerpress podcasting package rolled out and autoupdated behind my back. Since that also adds content to the dashboard, I disabled it. Dashboard’s back so that one’s not on Yoast. Now keeping in mind that *I have tried this specific test repeatedly*, I deactivate Powerpress and…everything works. Turn it back on and it doesn’t. Turn it back on without Yoast and it it does.

I’m not sure how the etiquette works these days but I’m going to try to reach out in their direction and point them at this thread as well. It’s definitely possible that I’m just incompetent at this point…but it seems very, very likely to me that there’s a specific conflict happening between these two plugins, possibly in specific configurations, that causes the (standard, with widgets from various plugins) WP admin dashboard to intermittently break and the block editor to *always* break.

I’m going to try a couple of toggles with powerpress after I track them down and link them here, and will follow up.

— followup —

First, I did start a topic on the Powerpress support forum so hopefully they’ll see this. I did some testing, just to see what would happen.

– currently, with the latest build of Powerpress that dropped a couple of hours ago (call it…2000gmt-ish/4pmEST?) neither my WP dashboard area nor my block editor will work.

— I tried disabling the various in-process tools like dashboard widgets, toggling off tools in the block editor, etc. Even with those tools toggled off, the effected pages will not load with both plugins enabled.

I can work around this for now for my purposes, now that I know what the problem is; I just have to rather inconveniently toggle powerpress off and on to use the block editor and will have to fumble around with the classic editor to publish podcasts until a fix is found. The dashboard problem is inconvenient but I don’t spend a ton of my worktime on that page proper anyway, and all other functionality (except the block editor) appears to be functioning as normal with both plugins activated. This includes all admin and settings pages specific to both plugins.

Sorry, I know this is convoluted and ultimately probably affects three people on the whole planet…but I know how this kind of thing can sit dormant and bite you later when you think the problem is “solved” because the few people impacted just moved on instead. I don’t really have the spoons to do things like load up AIOSEO and try THAT with and without Powerpress, etc., but the earlier-mentioned fact that this error appears to impact basically any full-functioned SEO plugin may give a clue as to what’s causing it and why it appears to be limited specifically to interacting with something Powerpress is doing (although it may not be limited to them either; I’m just one person with one setup).

I hope all this noise helps, please let me know if there is specific information I can track down or add for you. The one thing I *haven’t* done is set up a testing domain with JUST these two plugins to see how THAT plays out and if maybe there’s yet a third problem; I figure if we hit a dead end here then that’s a next-step testing tactic I can try.

• This reply was modified 3 years ago by JohnHenryUS. Reason: added further info post-test

PS: also tried toggling various in-app switches like readability check, no love. Even crashes “page” editing when I have the “page” type excluded from the plugin. Also, sometimes it will crash the dashboard page for no discernible reason. (It’s doing this now on my site even though I’ve changed nothing since I originally wrote this comment.) Other areas of the admin section appear to work as normal, just the dashboard site.

Is there perhaps some data being pulled from somewhere common to the dashboard widget and the block editor that maybe my site is being slow about and that’s causing the hangups?

• This reply was modified 3 years ago by JohnHenryUS.

Poking in because this was driving me nuts (and I was driving my host nuts. I can report that the above solution by tri5 works. (I also implemented boomhauer’s tweak, and I’m running php7 on IIS)

Yessir, that did it! I had to do the same process with LGN – it stopped appearing in the WP/sites dashboard – but now they’re both there as independent entities. Thank you so much!

Sure thing. Old site: https://www.lowgenius.net New site: https://www.johnhenry.us

It appears that it is an OT-related issue.

I just got this back from my host. Two messages. The *second* message is that rolling back to PHP 5.2.17 (instead of 5.4.23) makes the theme work. Obviously this isn’t a real fix, since we don’t want to rely on running an older version of PHP. As I can clearly see that this code section is using option-tree specific variables, I have copied this message to support topics at both the Hueman theme and Option Tree support fora. Hopefully between the two of you, you can figure out what’s broken and how to fix it so it works in PHP 5.4.23+ ??

The first message is this list of errors:

===================
PHP Warning: Illegal string offset ‘background-color’ in D:\Inetpub\vhosts\lowgenius.com\staging.peoples-news-network.com\wp-content\themes\hueman\functions\dynamic-styles.php on line 219

PHP Warning: Illegal string offset ‘background-image’ in D:\Inetpub\vhosts\lowgenius.com\staging.peoples-news-network.com\wp-content\themes\hueman\functions\dynamic-styles.php on line 220

PHP Warning: Illegal string offset ‘background-position’ in D:\Inetpub\vhosts\lowgenius.com\staging.peoples-news-network.com\wp-content\themes\hueman\functions\dynamic-styles.php on line 221

PHP Warning: Illegal string offset ‘background-attachment’ in D:\Inetpub\vhosts\lowgenius.com\staging.peoples-news-network.com\wp-content\themes\hueman\functions\dynamic-styles.php on line 222

PHP Warning: Illegal string offset ‘background-repeat’ in D:\Inetpub\vhosts\lowgenius.com\staging.peoples-news-network.com\wp-content\themes\hueman\functions\dynamic-styles.php on line 223

PHP Warning: Illegal string offset ‘background-size’ in D:\Inetpub\vhosts\lowgenius.com\staging.peoples-news-network.com\wp-content\themes\hueman\functions\dynamic-styles.php on line 224

======================

All of those strings are used on those lines, within the following conditional:

(line 215) // body background
if ( ot_get_option(‘body-background’) != ” ) {

$body_background = ot_get_option(‘body-background’);
(L219) $body_color = $body_background[‘background-color’];
$body_image = $body_background[‘background-image’];
$body_position = $body_background[‘background-position’];
$body_attachment = $body_background[‘background-attachment’];
$body_repeat = $body_background[‘background-repeat’];
(L224) $body_size = $body_background[‘background-size’];

================

I’m no PHP coder, but I *am* a rusty old ASPX coder. This appears to me to be an error created by an OT-specific code segment within the theme when there is a value set for variable ot_get_option(‘body-background’). As I’m not familiar enough with PHP to chase down where, precisely, this string is set by default to a non-null value, I will leave it up to you talented folks to determine precisely what the problem is and how to fix it. I’ll be monitoring these threads so I can fix it by hand ASAP, in anticipation of a later, formal fix pushed out in a theme update (after, I’m assuming, a fix is pushed out through OT as it seems likely to me that OT is generating this code.)

Thanks for your help and patience. I will keep you posted in the event we’re able to isolate and solve the problem.

NB: The same thing happens with “Anew.” I just tried it. I don’t know if that will help narrow down which component may be causing the issue. I’ve also submitted a ticket to my host.

Well, I am glad I tried this on a testing server before deleting my existing install – still a 500 error, this time with a *completely* fresh install, and again the only thing added is the Hueman theme.

Are there version checks I should make to MySQL or anything, or is there something in particular at which I might point my server support personnel?

If it helps, activating Hueman *totally* crashes the server; even the admin area throws a 500 error. This tends to suggest that there’s something that is called by Hueman – probably custom settings submenu – when loading the administration page, that is also called when the “front” of the site loads.

I’m afraid my next test will have to be trying to install a *true* “fresh” WP – that is, downloading, unzipping, and uploading. I hope to avoid this, as it will mean I need to recreate content and re-install plugins now. Still, better to do it at this stage than after the site has months of content on it.

No, this is just something I tried on a hunch. I will disable and remove the plugin, as I have no plans to start developing themes for WP. (No change in behavior after disabling)

(working along and continuing to try different things) I have also just downloaded and installed the latest version of the OptionTree plugin. Still no luck.

I am more than happy to work with you step by step with config file settings and so forth; my site is currently in early days and I *really* like this theme (I would say I love it, but having a close friend from Finland broke me of the casual use of that word LOL). The features including typography and high degree of available customization make it a perfect fit for the type of news-magazine site that I’m trying to create…and the theme I am currently using (ProMax) is the best available of poor second-place choices.

Could this perhaps be related to some sort of broken scripting on the automatic installation process (which is handled through the Plesk control panel)? I realize as I consider this that I should not have claimed a “clean” install as I cannot be 100% certain that this is the case! As far as I can tell – keeping in mind that I am a rusty ASP/ASPX programmer and not a PHP programmer – it does nothing out of the ordinary except automate the creation of a database and insertion of necessary account variables in configuration files (e.g. db username and pw). (Again, this is a matter of personal convenience/ease of use; I’m far more familiar with MSSQL than MySQL.)

I will also be more than happy to communicate any issue resolution to my hosts, should we find that their install coding is the root of the problem. Anything I can do to facilitate the greater use of your wonderful theme, I am happy to do…if we can get it working ??

Best regards,
-jh

(Also, I did install from the download link, rather than the built-in WP theme manager; no change in behavior.)

Sorry for the delay, for some reason I’m not getting notifications on this post.

I have tried multiple themes. The only other one I tried which threw a 500 was “CodePeople-Light.” The server is running PHP version 5.4.23 as Fast CGI with CGI and Perl support turned on as well as support for server-side includes and “additional write permissions” (i.e. onsite scripts are allowed to write to disk) allowable. I do NOT have Python support turned on.

My host is Midphase; I’m running on IIS 7.5 (I can’t change this; I’m running ASP.Net apps on the same server space.) I can access the raw server logs, but looking at them didn’t tell me much other than verifying I threw a bunch of 500 errors.