Abigailm

OK,I figured it out. I ran a clean install on a staging site to eliminate any possible issues from my child site or plugins. This is definitely due to differences in theme options.

Here is what needs to be done to match previous settings on the menu:

1. In Theme Options, go to Typography > Menu and set color for the “Main Menu Font”

2. In Theme Options, go to Styling > Menu and set color for “Menu hover font color”

3. This will still leave you with a transparent background if you have a light menu. Under Styling > Menu there is a premium option called “Custom menu hover background” that might solve that problem, but assuming you are sticking with the free theme, you will have to add the following custom CSS specification:

ul.nav-menu ul {background: #eee;}

(where #eee can be substituted with whatever light color is appropriate for your theme).

You might have to add an !important specification to make it work. (I didn’t test things that far — I just made the adjustments using the browser developer tools).

There is still another display issue with social media icons on home page (increased spacing) and I haven’t had time to go through my staging site whatever other layout issues have been introduced with this upgrade. I haven’t updated the theme on my live site and will have to give it all more thought before I do.

Just for anyone else reading this — I figured out that the problem was with the header template in my child theme, so I disabled that. But that just gave rise to a new problem- the styling for the main menu has been changed so that there are light fonts against a light background on hover & drop down, and the menu is virtually unusable….. so upgraded theme is still unusable.

No cache plugin. Not a browser cache issue, I opened a fresh browser to check It’s a staging site, exact clone of live site. (I learned my lesson about Evolve theme upgrades the last time around)

I can’t post URL/login info publicly — is there way to transmit that info privately?

OK-that worked — switching the content to the a custom field works fine.

If a fix isn’t likely in near future, it might be a good idea to document this at http://pods.io/docs/learn/what-are-custom-fields/ — just a short note that points out the benefit of creating a separate custom field rather than using the wordpress default editing box, for users who plan to create and display multiple pod types.

I continue to be amazed and delighted at the power that Pods give me, but it’s something of a learning curve and this is an example of a problem that would have been prevented if I had simply known of this quirk from the outset.

OK, I think I figured out what is going on .. I just need some pointers on how to fix it.

My testimonial custom post uses the main post text field for the substance of the testimonial, along with specialized custom fields for related info (name, location, etc.)

The widget template has a call to the magic tag {@post_content}

That works fine on most pages, but when it is on a page set by a template for a different custom post type, then I think the dual calls to post_content are creating a conflict.

So here’s my question:

Is there a some code I can use to limit a magic tag only to @post_content for the specific pod type — for example, I tried @testimonial.post_content — it didn’t work – but I am wondering whether there is some other syntax I can use to get that result.

Or is there something I could do with the where specification that would achieve the same result?

If I can’t then the obvious solution would be to simply create a custom field in the Testimonials pod and move the appropriate content to that section- but I thought I’d ask if there is another option first.

I just tried to install WP Staging on another site — same server, but I chose a site that is using a simple theme and has few plugins. On installation I got this error:

WP Staging File Permission error: /home/...../wordpress/wp-content/uploads/wp-staging/clone_details.json is not write and/or readable.
Check if the file /home/..../wordpress/wp-content/uploads/wp-staging/clone_details.json exists! File permissions should be chmod 644.

WP Staging File Permission error: /home/...../wordpress/wp-content/uploads/wp-staging/remaining_files.json is not write and/or readable .
Check if the file /home/...../wordpress/wp-content/uploads/wp-staging/remaining_files.json exists! File permissions should be chmod 644.

I checked and those two json files were NOT in the appropriate subdirectory.

I then went back to the site where I encountered the 500 server error and checked, and those two files DO exist, but their date does not correspond to installation date. Before I reported the problem here, I had uninstalled and reinstalled the WP-Staging plugin- because sometimes it helps to work with a fresh installation – so all plugin files are dated 4/18. However the json files in the uploads/wp-staging directory have file dates of 4/3/16 (probably from when I first installed WP-Staging). That’s fine if there has been no change in those files, but if there has been a change then it’s possible that there could be an issue with the WordPress distribution.

Thanks — that makes sense because I did enable WebP conversion.

I did figure out what is triggering the error on at least one site. It gets triggered when the Baidu spider looks for an /embed/ subdirectory — that pulls up an xml page with picture but also triggers 2 instances of the PHP error every time it happens.

If it turns out to be the same cause with the other site, I’ll see whether I can simply block Baidu via robots.tx