mwarbinek

No, the leprechaun is still dancing.

I refer to your statement of getting into more detail.

Yes, I just checked a new download of WordPress and that folder is there with the PHP files. They have apparently been doing this since version 3x. personally, I think it is time not to include them because these PHP files can open the door to hacking since they are old ones.

You suggested to work more along the lines of the initial issue, what did you have in mind?

• This reply was modified 8 years, 6 months ago by mwarbinek. Reason: Added content

Platform is WordPress newest version and it occurred with the newest version.

I did find something odd in the file structure of a few WordPress sites, especially the install that showed the conflict with Edit Flow. I found the “theme-compat” folder under wp-includes. Apparently this folder and PHP files are

The theme-compat directory is comprised of a set of deprecated (since WordPress 3.0) files that WordPress used to use as fallback template-part files, in case the active Theme failed to include them.

In other words, if a Theme used the get_header() template tag, but failed to include a header.php template-part file, WordPress would fall back to /wp-includes/theme-compat/header.php.

The template-part files in theme_compat are deprecated, unmaintained, incredibly old (by core/current-Theme standards), and should not be relied upon by any current Theme
– https://wordpress.stackexchange.com/questions/54503/what-is-theme-compat

Does that have anything to do with it?

• This reply was modified 8 years, 6 months ago by mwarbinek. Reason: Added content
• This reply was modified 8 years, 6 months ago by mwarbinek.

So what fixed it? Deactivated the debug in PHP? (curious)

https://i1241.photobucket.com/albums/gg518/BattleWarrior/dancing-leprechaun.gif

Looking forward to this update. ??

Thanks.

• This reply was modified 8 years, 6 months ago by mwarbinek. Reason: added content

Default WordPress Themes – Yes I did test a default theme and the problem remains.

Warning Display – the JetPack dashboard is the only place the warning is displayed.

So far this error has not effected any other function or part of WordPress, front or backend.

You can see a screen shot here: PHP Warning in JetPack Dashboard

• This reply was modified 8 years, 6 months ago by mwarbinek. Reason: correction

Thanks for the reply.

WordPress 4.6.1
Edit Flow 0.8.1

The parts that I left out refer to the root folder and subfolders of the server and due to hackers, I do not want to reveal how the folder structure is setup.

So it will look like this:

Warning: Cannot modify header information – headers already sent by (output started at server/root/wp-admin/includes/template.php:1969) in server/root/wp-includes/rest-api.php on line 361

Without revealing certain folder names, that is what the error said.
Does that help?

• This reply was modified 8 years, 6 months ago by mwarbinek.
• This reply was modified 8 years, 6 months ago by mwarbinek.

I appreciate the clarification and the help. I am sure others appreciate it too.

Will do the fix.

Thanks

Sorry, this is not good, Fruit Code. Here is why.

The GitHub download page shows 2 fixes for the meta description, both from the same author and both are different from each other. Which is the proper fix?

This method to go to GitHub is not good for general users who have a limited (if any) understanding of PHP. They won’t know what to do with GitHub or how it works, let alone download anything. It’s not good to assume the general user can understand what you refer to, they don’t work at the same level.

Best to include that in the next update and let us know when because it is a obvious bug.

Yep, that’s the corner office ??

To get to the folder named “load”, you need FTP access or File Manager in Cpanel.

• This reply was modified 8 years, 6 months ago by mwarbinek.
• This reply was modified 8 years, 6 months ago by mwarbinek. Reason: correction

Sure, a Meta tag description field box in the settings would work. – However it is done.

I found the cause of the problem.

Inside the “load” folder there is an index.php. The coding of that index file provides for the insertion of HTML <head> “meta” tags.

These are the offending lines that caused the problem,

Line 26:
<meta name="description" content="...">

Line 30:
<meta property="og:description" content="...">

You inserted a PHP echo command that pulled the information from the description field box and if that description field box contains any HTML coding, it breaks the <head> META tag and causes the browser to render the HTML inline and block styling codes like <div> or <p> or <span> etc.

Since the description field box in the plugin settings can accept HTML coding for some content styling, your going to have to fix the bugs. I think maybe use a different field box in the settings page that we can fill out specifically for the meta tags and not use the “description” function (description field box content) to insert content into the meta tags?

FIX
How I fixed it was commented out those offending lines and once done, the description text and HTML code will not appear. Although, that defeats the use of those <meta> tags, which is why you need to fix it.

• This reply was modified 8 years, 7 months ago by mwarbinek. Reason: Added content

Oh, my bad. I had assumed you had been in touch with us about this already, but I understand now that you were referring to other threads on these forums.

I referred to other threads because I was researching for a solution, so when I read about checking which site is causing the issue, I decided to take that method and find out. Turns out it actually fixed the issue and because it worked, it appears that one caused a connection error that affected the other as well. So shutting down both (deactivating) and re-activating one at a time and checking it fully resolved it.

That most likely indicates issues with both sites. It would be worth looking into this.

Sure, but since both are working now, how would it be possible to find out? (Unless there is some log to refer to).

How would we find out now?

Understood! Would you imagine that notice appearing on all pages of your dashboard, or only in the Jetpack menu?

Mmmm, normally a person is on the JetPack “lets connect” page when he connects to the WordPress account, then connects to WordPress by signing in, once signed in, it takes him back to the JetPack page, so when it takes him back to the page, then a suggestion that an alert says “Please wait till JetPack checks the Connection…”, then the result, “JetPack is Connected and Working Fine” if all works good including plugin list connection, or “JetPack connection failed – Plugins are not fetched – check (whatever)” if it fails.

Of course I leave the actual dialogues to the JetPack Dev’s.

That would alert the user to problems at the first site that causes a bad connection instead of maybe after the 100th, then having to go back through a long trouble shoot to find which one.

Instead of deactivating Jetpack, you could have used the site switcher in WordPress.com’ sidebar to only view plugins for one site at a time. You would have then seen which site generates an error, and which one doesn’t. It might be worth a try next time.

I did that, both showed fetching errors.

Do not hesitate to reply to the last email you received from one of my colleagues. If you know what site you had trouble with, we can look into that site’s connection to try to understand what happened.

I have not received any emails yet.

You can use Jetpack’s Debug menu in your site’s dashboard to find out more about your site’s connection to WordPress.com. If there are any issues with your site’s connection, it will be displayed there. To access that menu, you can go to the Jetpack menu in your dashboard, scroll down to the bottom of the page, and click on Debug.

I was referring to a label that appears like the update WordPress one. That idea to confirm all is connected and working. Then use the debug if the alert shows a problem.