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