Pretty links

You should select in the following page what is going to be checked:
https://monosnap.com/file/788AGwSI8lKXQ1gDJvDezBjb2AjJxJ

If these links aren’t included in your selections above, then it’s normal not to be reported.

Hello @emarketmedia ,

So i’m putting these links into posts and pages.

All Pretty Links generated are not used into posts. Could this be related to problem?

Could you confirm that we are on the same page here – not all of your links are used in Posts or Pages and those are ones that are not checked? Or plugins is not checking those that are in the posts and pages on your site?
If links are not used anywhere then as my collegue said

If these links aren’t included in your selections above, then it’s normal not to be reported.

kind regards,
Kasia

links generated with Pretty Links are not used in any post but they are used on “Table Maker” plugin.

And the Table Maker plugin outputs its tables to pages or any other specific custom post types?
Cause this is where Broken Link Checker should search for links.
Please advise!

Thank you,
Dimitris

Hello @emarketmedia

This sounds like a limitation of the Broken Link Checker plugin.
Just so I can further investigate by replicating this, are you referring to this plugin? https://wordpress.org/plugins/table-maker/
Please advise!

Thank you,
Dimitris

Hi @emarketmedia

I just did some testing and it seems that you’re right and Broken Link Checker indeed doesn’t detect those links if they are displayed via the Table Maker.

So I did a bit more digging and it seems it’s a very specific case related purely to the Table Maker plugin which stores its data in a very “unconventional” and completely non-standard way:

– each table, regardless how big and complex, is just a single row in the separate database
– it’s own database of the plugin so it’s not “registered” in a way e.g. custom post types or custom fields are (hence, you can’t see it in Broken Links Checker’s “Look For Links In” settings)
– furthermore, the content of the tables (cell values) is a base64_encoded data (all together).

In other word, you can’t even do a search for any part of table content in the database – you can’t find it, it’s “unrecognizable”, so to say.

When a shortcode is processed, plugin’s code is fetching that table data and decrypting it but that’s it. It appear that due to the very non-standard and unexpected approach to data storage in the Table Maker plugin, those links are literally “invisible” or “non-existing” to the Broken Link Checker. In fact, any “parser” script that takes content from the database wouldn’t be able to detect and check them due to the way they are mixed with the rest of the table data and then additionally encoded, I’m afraid, and making it work would require either a huge rewrite of the Broken Link Checker plugin specifically for supporting this very specific Table Maker plugin or a change of a Table Maker plugin to use more “standarized” approach to data storage.

Kind regards,
Adam