The-seo-framework: Can TSF Address Facebook Debugger Warnings?

[GuardianMajor]

When running the Facebook debugger on posts that don't immediately show up correctly based on their meta values, you see something like this:

Inferred Property
The provided 'og:image' properties are not yet available because new images are processed asynchronously. To ensure shares of new URLs include an image, specify the dimensions using 'og:image:width' and 'og:image:height' tags. Learn More

Extraneous properties specified
The following properties are specified on the webpage but NOT supported for the specified 'og:type': article:publisher, article:author, article:published_time, article:modified_time

With regard to the first one, is TSF able to provide the og:image:width and og:image:height values to alleviate this issue they complain about? Wondering if upon putting in the link to the "social image", it can perhaps parse these values and include them upon posting to effectively resolve this? It appears to also affect Google+ using their validator shows issues as well (among a few other complaints), which I will post an issue for separately (See #286).

Now the second one, I understand that while perhaps they don't use those values, others might? Am I correct in assuming that? or is it something that can be reasonably removed and no longer relevant?

I tried to keep it short this time like you asked, hopefully I have given you enough information. If not, please let me know. TIA.

[sybrew]

Hi @GuardianMajor

Thanks for keeping it short and sweet 😄

TSF does provide the dimensions if the image is selected via the WordPress image editor.
This can be done using the fallback image, featured image, and the in-post SEO social image.

For the extraneous properties, be sure that no other plugins or even the theme outputs meta tags.
TSF, especially in recent updates, has tightened its internal checks to prevent such extraneous properties being outputted.

P.S. The structured data testing tool isn't meant for Google+, it is meant for Google Search.

[GuardianMajor]

@sybrew I try, especially when I know it is preferred :smile:

The "social image" that I put for each given post, I use the full URL path, sometimes selected using "select image" button but usually manually provided, so not using the image editor (if I understand correctly) and so it won't be grabbing the dimensions then, correct?

There are no other plugins that would add those extraneous properties but I will double check to see if the theme perhaps is doing something stupid or not, let you know.

[sybrew]

Hi @GuardianMajor

That's correct, you understood correctly 😄

I await your response regarding your findings. Cheers!

[GuardianMajor]

@sybrew Great, thank you. Is there any way, either by default or by option we can have that information included no matter if the image is selected through the editor, or by choosing the image from the media library, or by path? During the validation and publish, it can grab all that information from the image, no? Just thinking that would be a very welcome enhancement and appreciated.

I checked every bit of the site code, the theme and all plugins and found that nothing is inserting those "extraneous" meta tags, so can you please help me figure out why they are there? Is it perhaps WP itself inserting this? Just thinking out loud. Thank you.

[sybrew]

Hi @GuardianMajor

Interpreting image dimensions on-the-fly is technically possible, but very resource intensive. This is also the reason why Facebook prefers you supplying it.
Shared hosting doesn't have enough power for this process; thus, we have not included such technology, and we rely solely on WordPress' media meta database.

I currently don't have the time to do technical reviews. I must ask you to outsource this, for the time being. The errors could range from simply bad caching at Facebook, to routing issues from the server your website resides on. If this isolates towards plugin issues, I'd be happy to investigate further.

What will help me in the meantime is providing me the og:type used on the specific page. with the extraneous properties. It'll allow me to quickly identify the cause from code.

Cheers 😄

[GuardianMajor]

@sybrew

I see, I was hoping that leveraging WP's existing infrastructure could aid with that, as it uses the same resources to generate this as the plugin would 😞

I know you don't have time and I wasn't asking for you to do the work, I am happy to do it. But since the theme, WP, plugins are not doing it and there is no routing issue and since the posts are new there is no existing Facebook cache for them, I was trying to make sure it is not somehow getting missed within the plugin and getting added.

As for the og:type it is listed as <meta property="og:type" content="article" /> within the page code and Facebook detects it as such too og:type article hopefully that will help. Thank you.

[sybrew]

og:type of Article should have those named "Extraneous" properties. So this must be an external issue.

Simply use the Object Debugger to fetch new scraping information. When it's still giving errors, Google the error and you'll know the cause.

Note that Facebook has bugs too, and we provide everything according to their specification. I update the plugin accordingly if anything changes.

[GuardianMajor]

Correct but why it is giving a warning saying that they are extraneous is the part that makes no sense, if it should be expecting it, right?

Interesting part is that when using Object Debugger the warnings are not there but if you use Sharing Debugger it does, perhaps they are applying different rules in these cases which is frustrating to say the least - so agreed they might be the ones applying their standards inconsistently but given how long it has been happening, you'd think it would be addressed by now if a legitimate issue on their end.

In either case they don't show og:image:alt which should be passing along and of course the already discussed og:image:width and og:image:height which after you click scrape a couple of times stops showing as an issue, although it is missing from the properties shown.

[GuardianMajor]

I came across a bug report that makes the claim that Facebook has an issue when images are coming from HTTPS, suggesting that it needs the property og:image:secure_url to work properly and when it received the HTTP equivalent of og:image only that's when the image issue is encountered.

Not sure if that applies to us regarding the first issue (not including the :height or :width issue) since my site is HTTPS and all I find are og:image links and nothing involving the og:image:secure_url, is this something that we need to address, at the very least for sake of completeness?

For the height and width issue, I am working on a "shortcode" style filter function that would add those on the fly as the post is published, will have to tweak and test extensively and make it efficient for the time being; but question - would you be interested in me sending that to you when it is done to see if it is something we can leverage for TSF without putting the resource harm you mentioned earlier in parsing that information to pass along and provide the feature?

I was exploring the TSF code and found that where you get the information for the og:image (in the generate-image-class.php) you can relatively easily use imagex($src) and imagey($src) to grab the dimensions on the fly (or if you prefer to work with arrays, in a single shot from getimagesize() ) without being from attachment (where you are checking for id) or editor (again where you are checking for id) when explicitly provided and use the URL that is in the social image (which you are already assigning to og:image) provided to grab the dimensions on the fly without any performance or resource hits at all since they are native PHP functions that near instantly provide that information. Thoughts?

[sybrew]

Hi @GuardianMajor

og:image:alt isn't mandatory. But, we could apply it.
In any case, I've yet to test its usefulness. More on this is found at #199

og:image:secure_url is difficult, if not impossible, to implement correctly in WordPress. Note that it's only needed when you serve your website via http instead of https.
On top of that, your website should permit access to https, whilst serving a valid certificate. When a user serves an http site, it's very unlikely that the server is correctly configured to serve https.
In this day and age, it's also irresponsible not to use https for your website, especially since Google puts pressure on it. Therefore, the Monitor extension notifies you on this.

Regarding image width and height determination: What you've explored is exactly how we extract information.
However, when no ID is provided, we need to follow the URL to obtain more information; or, otherwise manipulate and cross-reference it within the database.
In either case, image editing functionality isn't in the SPL, they're add-ons.
Secondly and to reiterate, it uses a lot of server resources and can require additional cURL requests. Both can result in lagging and timeouts. When they're not resolved correctly, we need to flag it as erroneous and then maintain that error state. So, there are many bugs to resolve this matter, and I just emphasized one of many.

The tradeoff for not implementing it is that:

1. Facebook suggests you should add those dimensions.
2. Facebook requires a little more time before it shows the image, instead of directly.

Both of those tradeoffs are negligible, and I find there are many other more important matters to resolve.

Something to think about:

For every minute I spend developing something, I require 2 hours more maintaining and providing support for it. By this logic, I already have 230 work-years cut out for me. This is still manageable, especially when I find colleagues.

This is also why it took me so long to reply. I simply can't find the time to discuss these matters in detail. When I make up my mind, I hold many good reasons for it. The time it takes me to expound and lay justification for these reasons is huge, and it's also very difficult to do so.

So, I want to ask you to please trust me on this matter. I'm very open to bug reports and suggestions, and I'm not one to fall for fallacies. But, I can't nor am willing to discuss technicalities for features or current implementations in great detail.
Also, what might work for you might not for many others: This plugin is built to work with every WordPress site, not just a few.

[GuardianMajor]

@sybrew Hope you are doing well.

I know it is not mandatory, I was simply asking since we have the information and it is expecting it for whatever reason, it wouldn't be difficult to include it. Thanks for the link, I see you have it on your to-do so that's all we can ask. I am still waiting for the option to strip the tags to be introduced, so I know you have a lot to do, it is something that can wait and the consideration is appreciated.

I appreciate your thoughts but my site has always used full HTTPS and has been serving as such since its inception, so that's not an issue for me, in fact I serve no MIXED content of any kind and when necessary will make the resource local to ensure it is always delivered as secure. That's why I was thinking it shouldn't actually be too difficult given that you can simply call the built-in function is_ssl() and act accordingly (Reference) Basically IF TRUE add the link you _already have_ to og:image:secure_url and IF FALSE don't. If you wanted to be extra vigilant, you can even do a preg_match in addition checking for the https:// protocol. I only brought this up as it was discussed out there and figured it might shed some light, if you don't think it is needed or resolves a problem, then by all means leave it out but it certainly can't hurt, at worst a redundancy that might resolve some edge issues. The Monitor plugin is something I had already considered and been looking into, so might very well end up having that added for the next revision of the site (planned for about mid year) hence why I am trying to nail everything down now in preparation of the next iteration.

The image dimensions matter, I understand is not a burning hot issue but it is one that can easily be resolved. You already have a robust check system in place, and adding the else check is frankly academic for you without much effort. Now I understand your concerns with the resources needed to do the check, but what I don't understand is how you feel it is more intensive to use a native function. Even with the ID, WP has already used the resources to get this information and you are making calls to parse it, while I get that you see that as less resources to parse, you already have the link (aka $src) that you are putting in there for the og:image so passing that to a function like I mentioned is no more resource intensive than any other function calls you are already making. You don't need to create and cURL calls for it (or follow the link) as they are existing PHP functions that are loaded and available to the code already. All they require to provide a response is the URL parameter and you already have that in hand at the point of making the call and the function handles the rest server side which is negligible. I did a small test on my end and found absolutely no measurable hit to performance at all between you getting it from the WP db, image editor or the internal functions. Understand please, that I am not challenging your conclusions or debating it to change it, and have full respect for the time you have already dedicated to reach those decisions; just providing context for enhancing what you have already done excellently to improve functionality, nothing else. I will address your feelings on this more as I get to the next portion of your reply to clarify more but I am also concerned with this getting too long - so bear with me.

Now about what you said to consider. I know perfectly well the extent of the commitment and the huge amount of burden that comes with it. I am fully aware and appreciative of that, I have spent more than 25 years in the industry and have spent much of that time maintaining open source free software that requires a huge commitment with no payoff done basically out of love and passion. I know how it wears on a person, so I never take for granted people's work and in no way EVER should you feel that I do that here with you, it goes against everything I believe and support. NOTHING, absolutely NOTHING, that I discuss with you is EVER meant to devalue what you have done, doing and will continue to do. I have too much respect for good code and the developer who built it to be that way, it is not my nature. That's why I invest the time to discuss it with them, if I didn't care about them or their work, I would never invest so much time on it. I feel that the least I can contribute is context and potential improvements to better what they have already accomplished, never ever to tear them down. That being said, I am more than happy and willing and qualified to help you in any way you choose. If you wish for me to be more involved and provide assistance in ANY capacity, I would welcome it and be more than happy for the commitment. I just don't offer without indication that it is wanted, because some people mistake it as trying to crash their party and I would never want them to feel like someone is criticizing their work in any way. I can ever help with feature review and code review if you ever have a "beta" build you want to test with another pair of eyes, I would happily do that for you, I have access to various production and dev configurations to test that with pleasure. Just let me know. Again, sorry this got long but I didn't want to leave doubt on my intentions and make sure you knew that none of this a challenge or question against your work or intent, just trying to be a good end-user (at least right now) to provide feedback, that's all. Innovation comes from debate, that in itself is never meant to be disrespectful or a challenge. Nothing is intended to make you justify anything, just to think it through to see if context can provide resolution to any gaps, nothing more. That's why I have never pressured you or demanded that you drop everything to respond on a timetable, I have always been conscious of life commitments and have been diligent but patient because I know you have a lot to manage already, I don't want to add to the burden.

Take care my friend and again apologies this got longer than I had intended. 🤝

[sybrew]

Hi @GuardianMajor

I have the utmost respect for your commitment, and I truly take your kind-heartedness with warm regards.

og:image:secure_url:

There are no downsides to not utilizing the og:image:secure_url. I've never seen evidence proven otherwise. Now, Facebook (as Twitter) can stream third-party videos. Facebook doesn't cache those, so they do want it provided there.

Here's a link to their documentation: https://developers.facebook.com/docs/sharing/webmasters#media
Once more, there, they don't explicitly state this is required for images, whereas they do for videos.

If you can explicitly prove me wrong on this part, please provide evidence.

og:image on-the-fly dimensions:

Now, if you can run the aforementioned image size requests on-the-fly on a server with these configurations under 0.01 seconds and using less than 500kB, then feel free to submit a PR:

1. PHP 5.3 - No opcode caching, 8MiB request size, 16 MiB memory limit.
2. Apache with DSO or FPM, and with at most two workers.
3. No caching plugins.
4. A few heavy plugins installed, like WooCommerce.
5. The image URL must run through $this->matches_this_domain() prior execution, and should return true.
6. The image must be 1MB or larger, i.e. an unoptimized one.
7. Two "users" requesting the page every second.

This is roughly a "low-end" shared hosting environment demanding too much. Which, unfortunately, too many users are running.

Here's a template:

$timer = microtime( true );
$mem = memory_get_peak_useage( true );

if ( $this->matches_this_domain( $url ) ) {
    // Code here.
}

echo 'Time to parse image: ' . number_format( microtime( true ) - $timer, 5 ) . ' seconds';
echo "<br>\r\n";
echo 'Memory to parse image: ' . number_format( ( memory_get_peak_usage( true ) - $mem ) / 1024, 3 ) . ' kB';

[GuardianMajor]

@sybrew Great to hear from you and apologies for delay getting back to you, I was dealing with health matters and this is the first chance I have had to sit down.

I have no interest in proving you wrong and find your explanation acceptable and have no reason to doubt it at all. As I said, I simply brought it up because it was tossed around the WP forums for a while (meaning spanning several years) as the reason for the "parsing" issue and I figured I share, I have no dog in the race on this or a position to defend, so we are all good. It is entirely within your prerogative if you wish to add that since we have it anyway or not. I am ok either way, I trust your judgement and have full confidence in your understanding of it.

Ok, understood. I see your concern here based on the specs you provided. My current minimums are set as follows (although to be honest, I have access to far more CPU/RAM than I have allocated).

PHP Version : 7.2.3
PHP Memory Usage: 40.19 MB
PHP Memory Limit : 256M
PHP Max Upload Size : 64M
PHP Max Post Size : 64M
PHP Allow URL fopen : On
PHP Allow URL Include : Off
PHP Display Errors : On
PHP Max Script Execution Time : 50000 Seconds
Debian GNU/Linux 8 (jessie)
Apache
No Caching Plugin

Allow me some time to setup and configure a barebone installation so I can test that for you. I will then share the results with you either here if you prefer or even privately through email if you so choose. I now have the requirements you want to stress test and that way I have a better idea of how to approach the test, not on my current system which is not feeling it for what now appears to be obvious reasons of having ample resources.

I will set this up and run the stress test and get back to you. As I said, due to teaching obligations and personal health obstacles, please allow me a bit of time. Thank you again for your efforts on this, I appreciate it as always. Take care my friend.

[GuardianMajor]

@sybrew I wanted to let you know that I am working on this. It has been going slower than I want because I have teaching obligations and health obstacles that keep exhausting my available time but I have been having a really hard time as of late (nearly a week) dealing with Facebook just being VERY VERY stubborn in detecting the OG data properly and I was wondering if I can ask you for one favor.

Until we can fully evaluate the stress of making it programmatically available, would you please consider putting a low-fi, very resource neutral option to temporarily resolve this issue by providing two boxes under the social image box to manually input the height/width that would be put in the proper meta. Something like this (a mock up for POC):

Here, since you are already grabbing the h/w for the image when chosen from media library or editor, you would simply populate those values in the two boxes. But, when it is not available, like when you are putting a link manually, provide the option to enter the h/w manually in those boxes and upon finalization assign the value in those boxes (whether they were put there through detection you are already doing or manually). This would in the interim immediately resolve this issue and give us more time to find a better solution while still providing the functionality?

What do you think? Are you game? 🙏

On a complete side note, since I can't comment to follow-up on the original issue, any chance this #270 is going to be released anytime soon? I know you have a lot to do and I respect that and don't want in any way to rush yo, but this would greatly speed up my life to stop having to manually set the titles for new posts right now and the old ones are all auto-generated and looking quite buggy and unkempt. Heck, even if you have a beta/dev version that you can toss my way to use on my own site just in the meantime, that would be personally very appreciated as it would relieve a lot of things for me. I would happily take this as an opportunity to provide feedback and beta testing data. Thank you again.

[sybrew]

Hi @GuardianMajor

Get well soon! 🏥

To get right to your proposal:

I think it's far too advanced for WordPress users. It's a gimmick for perfectionists that would ultimately confuse and strain non-savvy users in this field. Moreover, it allows users to enter incorrect data, which needs to be tested and kept up-to-date with other changes. Any account for this would (at the very least) be irritating the user.

TSF's AI is very good at grabbing all technical information required and provided by WordPress and its editors to assimilate metadata correctly.
Facebook's AI is very good too, but it requires a few seconds assessing the image when omitting noncrucial data points.

In short: Anything less than perfect is a waste of time; because it's already near-perfect the way it is.

For your title HTML tag question:

Issue 202 needs to be resolved first. And that's a big one. There's no ETA.
I provided a workaround, you should've been pinged already about this.

[GuardianMajor]

@sybrew Thank you my friend, appreciate it ❤️

Don't you think the inherent use of TSF implies some degree of competence for the users who enable it? The prefill method of the existing system would alleviate confusion and the empty to provide it manually will either be ignored by the user or used by those who know what it is. A small (i) hover can give them warning about leaving it empty if unsure what you are doing. Doesn't the benefit outweigh the potential "issues"? In fact, by default you can hide that to be enabled by the users specifically which implies they will bear the burden of using it properly. So the users who leave the defaults will never see it and that would alleviate much of our concern, and those who want it can just toggle the checkbox for it under say the Facebook tab of the TSF social configuration. Thoughts?

Just thinking out loud here, ultimately your call. I agree that a perfect solution would be best, but until you can reach that based on the considerations of it, it would be a useful stopgap measure. Doesn't say it has to be a permanent solution, just a lower resource bridge until such time "perfect" solution can be realized. The problem with Facebook is that once they have completed the "scrape" and missing data is not populated, it won't scrape again unless you go into object debug and force it.

For the title, I saw your reference and completely understand, thank you for the update on that. I did see your workaround and will be testing it. Quick look seems to be a very elegant workaround, thank you for sharing it. I will let you know if any "changes" are necessary but so far looking at it, seems very elegant, thank you.

[sybrew]

Don't you think the inherent use of TSF implies some degree of competence for the users who enable it?

Yes. And I want to step away from that 😃. I hate those reviews around the web stating "TSF requires SEO knowledge". The plugin comes pre-configured and has loads of AI in it!
I was the original person stating "SEO for everyone" before someone took that phrase and made it their own... and I want to keep to that statement and make it truer every update.

The issue with "patch-like" features is that they need to be maintained, and the outcome is always negative. They will either confuse users introducing them or otherwise anger users relieving them when exchanged. In the meantime, they cost me hours of coding (around it) too.

For instance, I don't believe Breadcrumbs should be a feature of TSF anymore. I believe it should be an extension. But I'll shoot myself in the foot if I make that switch, as nearly every user makes use of it.

Ultimately, this means every change I bring to the software, I need a damn good reason for it too.
As with Apple, with every (design) feature: bring 10 good reasons for why it would work. When you can't think of 10, drop it. For this change, I was able to list a few bad reasons, and that's not a good sign.

[GuardianMajor]

Ok then, I understand and respect your decision and approach, even if I am being honest I don't entirely agree with the narrow approach of it. Ultimately you are doing the work and I respect that and what works for your vision. I can only hope in time it will change to be more inclusive, even if not necessarily "clean" or "perfect" approach. As #202 shows us, even a perfect and elegant solution in hindsight needs reworking. Thank you my friend for your time.

[sybrew]

As for issue 202, it wasn't perfect nor elegant from the start 😅.

The WordPress theme title integration was--and still is--broken; at least, until they hard-deprecate wp_title().
When WordPress announced a new and better way of bringing titles in themes, I had to maintain two different systems, whilst trying to maintain all features that come with it.

Meanwhile, I was bringing features into the mix while not wanting to figure out how I hacked in the integration on the old part in the first place. All this became a bunch of very smelly code.
This is why it's taking so long bringing verbose titles and whatnot.

It was a rookie mistake, and I've learned from it. So much so I'm drawing hard lines everywhere.