Hi, Tony.

As we mentioned in a couple of your other tickets, such as this one (https://tmsplugins.ticksy.com/ticket/3155794/),

our support does not cover any SEO optimizations for our users.  

What you are seeing is the default behaviour of our tables and plugin - that is how the Google SEO is currently handling the data;

The only useful information we have regarding SEO is what we mentioned :

The tables are crawlable by search engines :

- Non-server-side tables (linked to Excel, CSV, PHP, JSON, XML, and Google Sheets)

 are crawlable in their entirety, 

while the server-side tables (manual, imported and MySQL query-based) only show the rows that are present in the table when the page loads.

-

Once again, i honestly wish we could be more helpful to assist you in SEO optimization, but our support is not able to cover it at this time.

We will do our best to work on adding improvements for SEO with our plugin's tables,

but i can't promise a realistic ETA on it.

If you have any ideas for suggestions on future improvements of our plugin,

please feel free to search on our suggestions page, 

 to see if someone may be already suggested this feature. If you can't see it, feel free to add your suggestion there,  and as more people vote, the feature will move higher on the priority list.

You can certainly follow our changeLog page if you'd like ( it is also available in the plugin dashboard), where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

-

Of course, we will be here for any other assistance that you might need - we will do our best to help as much as possible, don't hesitate to reach out if you have any other questions. 

Thank you

Hi, Tony.

Firstly, my apology for the waiting time on this reply.
We had our Orthodox Easter holiday break which increased the delay.
Thank you very much for your patience.

-

Thank you for this feedback and for the improvement suggestion.

I can see what you mean , we completely understand the need for improvement on the SEO front for a use-case like that.

We passed this to our developers, they will do their best to try to improve the SEO / have the tables be quicker to get crawlable in the future.

We can't promise a realistic ETA, but will do our best to work on that.

You can suggest the improvement on our user suggestions board,

and follow our changeLog, we will make a post there when this has been improved in the future.

Thanks again.

Hi, Tony.

No problem at all, we are here to answer any questions about our plugin.

I can completely understand where you're coming from and I agree with you, there is probably a lot of our users who can benefit from better SEO functionalities from our tables,

but at the moment, that is the default behaviour of our tables and plugin - 

that is how the Google SEO is currently handling the data.

Our developers take great value from our user's feedback, so thank you again for the feedback and suggestions.

We will do our best to somehow improve this, but we can't promise a realistic ETA.

You can certainly follow our changeLog page if you'd like ( it is also available in the plugin dashboard), where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

-

In regards to the question about forum of developers;

I am sorry, but we do not have any kind of a forum of developers.

Our developers are very busy at the moment, working on some priority tasks and fixing bugs and issues with our plugins, so they also won't be having the time for any custom work in the near future.

Hi, Tony.

-

I am honestly not sure about this,

we will check if our developers are able to provide some insight about this matter,

and we will report back as soon as they advise.

Thank you for your patience.

I will let you know if they need any further details/access from your end.

Hi, Tony.

Just wanted to let you know we are still following up on this case.

Our 2nd level has not responded yet - but i am expecting to get advised very soon at this point.

Thank you for your patience once again.

Hi, Tony.

Just wanted to let you know that we have now  escalated this with our developers.

And after further testing of the related page, https://farwestair.com/parts-listing/

i notice there are some invalid JSON responses from the tables on page, in the browser developer console.

The error messages with table ID's, for example for table 3 :

"Uncaught Error: DataTables warning: table id=table_3 - Invalid JSON response. For more information about this error, please see http://datatables.net/tn/1"
 

JSON errors usually occur if you have a security plugin installed, or there's a security measure blocking admin-ajax calls. 

Also, if the pages are cached, it can occur. 

Try excluding pages where you have our tables loaded from being cached, and try again.

If there's a notice, warning or fatal error WordPress that manifests through responses. 

Our table requires a valid JSON in the response, so if there are these notices, the JSON is not valid, and the data is not being loaded.

-

We will still check if our developers have any additional advice about the tables not properly working for the crawlable functionality of Google SEO, in the meantime i wanted to point out this issue we found as well.

Let me know if that helps.

-

Could we also get access to the back-end?

Please provide me a temporary WP-admin (administrator) user for your site where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue. 

We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties. 

You can write credentials here just check PRIVATE Reply so nobody can see them except us.

Hi, Tony.

My apologies, i should have spotted this earlier, all these tables that come up in the error are actually Manual Tables, which have our server-side processing enabled.

We will elaborate about this issue.

These errors can happen for a few reasons, but they always happen for server-side tables (MySQL, manual, or imported tables).

Check if you have any errors, notices, warnings in your console.

 If there are, resolve them first because they are interrupting wpDataTables' admin-ajax calls and the errors returned are referring to either bad Ajax or bad JSON response.

Another thing that could be causing this is the cache.

 If the data is being cached on the page, the returned data is not the same, or not at least what wpDataTables is expecting to see, so the error occurs. 

Try clearing all cache from your website and browser, and then prevent the pages containing wpDataTables from being cached.

If you're using a caching plugin, most of them have a setting to exclude URL's, so try excluding any pages that have tables and see if this helps ( it should).

Last, it could be the data in the table(s) - if the data is not the type that it should be (for example, a non-numerical value in an integer or a float column), or if the data has been changed for a formula column. Try creating a new table from the source table and see if it's going to cause errors. If it doesn't (after excluding cache as the cause), look for differences between data, filters, etc.

I hope that helps.

Hi, Tony.

In the meantime our developers have additionally advised on some points.

-

1. In regards to invalid JSON errors we found on the page :

Invalid JSON happens when the front-end page does not get the data JSON structure from the hosting server,

which means that something in that table ( or all the tables that have this error) has broke for some reason,

or it could be deleted from your database,  or  it's possible it is not loading due to some warnings or errors from WordPress - it does not necessarily mean that the JSON error comes from our plugin.

We advise to first check these tables you have on the page,

please check do they load on the back-end side in our plugin,

and if they load in the back-end, can you make a new blank Test Page, and see if the problem is the same on this page.

- If you want us to remotely check them at the back-end, please provide us with Administrator credentials.

Just make sure to send it in a PRIVATE reply, for safety.

2. In regards to Google indexing/crawling :

Google is not able to properly index this data because of the said errors,  because most probably these tables are not generated fully at the moment.

3. We also notice that you have some dropdown issues with our tables.

It seems you are using a JupiterX  Theme  which seems to have a Bootstrap version that has a conflict with our current plugin's Bootstrap Version.

We can see this in the console, as well, in this error, if we try to use a dropdown such as "Show X number of rows".

The error message :  'Uncaught TypeError: Popper is not a constructor'.

We had the same issue with another user, the same error, that mentions the "Popper.JS".

This user had the Theme JupiterX that was pulling these scripts such as 'bootstrap-popper'.

Here is what solved it for them, you can try it.

In order to exclude the Theme's conflicting script from the pages where tables are,

you can replace a function that is added in your active Theme or Child Theme's functions.php  file:

Find this :

function bootstrap_dequeue_script() {
 $pageID = get_the_ID();
 if ($pageID){ 
        wp_dequeue_script('bootstrap-js');
         wp_enqueue_script( 'bootstrap-popper', 'https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.11.0/umd/popper.min.js', array('jquery'), null, true );
         wp_enqueue_script( 'bootstrap', get_template_directory_uri() . 'dist/js/bootstrap.min.js', array('jquery','bootstrap-popper'), '4.4.1', true ); 
 }
}
add_action( 'wp_print_scripts', 'bootstrap_dequeue_script', 100 );

 and replace it with this :

function bootstrap_dequeue_script() {
 $pageID = get_the_ID();
 if ($pageID == 567){
        wp_dequeue_script('jupiterx');
 }
}
add_action( 'wp_print_scripts', 'bootstrap_dequeue_script', 100 );

You can use any text/code editor to do this,

just make sure to replace this page ID value in the code ( in our example 567), with your page ID where you have the tables.

If you're not sure how to find the page ID, you can see our article on 'how to find page ID' here.

- And if you have more pages with tables,  add them by following with a "two sticks" symbol (||), at the line that has the "if" statement, like this :

if ($pageID == 16608 || 16609){

Please let us know if that fixed the issue for the dropdowns conflict.

4. In regards to your question :

How do I see the path that the data is coming from on the Google Docs location? I am trying to research how to get Google to index the files and need the URL for each datatable. It would be nice to be able to get the URL from within the dashboard without having to go into the Google Docs environment.

- It is not possible to see this from the front-end pages for security reasons because we do not send the source path from which the table is created to the front-end.

- As far as tables created by Google Spreadsheets, all data is available at the page and it is available for Google bots to scan.  When the page will be scanned,  that depends on a lot of different factors, such as how many users visit your site, etc.

- There are no tables on your page that are made from Google Spreadsheets ( linked to Google Sheeets) as far as we can see,

so we are not sure if we understood the reason behind that question.

- For Manual Tables the Google SEO will only pick up the rows that initially load on the page/ in other words, just the first page, because all Manual Tables are server-side processing,

( unless if you set the default number of rows per page to "all" in the table's Display settings)

as we mentioned in some previous replies on the logic how our tables are picked up from the Google SEO ( server-side processing versus non server-side).

Hi, Tony.

Thank you for enabling the DEBUG mode, i have sent this debug error to our developers, i hope it might help to determine / or get closer to the root of these issues.

As soon as they advise, we will report back. Thank you again for your patience and cooperation.

Yes, i hope that we should be able to resolve this as soon as possible to get those tables crawlable.

Hi, Tony.

We were advised by our developers, they have inspected the error report.

The errors indicated in this report are not related to wpDataTables.

There is also no table from our plugin with this SQL Query ( as it is shown in the error).

-

That means that somewhere else on the site, such as possibly a Theme or another Plugin or a Code Snippet ( if you or someone else added it from your end) is using this Query from the error, which is not valid.

-

This column from the error 'target_indexable_id' no longer exists in database table named 'wp_d73dbysfbv_yoast_seo_links'  , 

which seems to be one of the tables from "Youst" Plugin, our developers presume.

So, the next step that we suggest is, if you can find where this is coming from and try to change it,

then check if the errors/crashes go away after that.

If the site keeps throwing this warning, this is interfering with our plugin's JSON and it breaks, because the WP error happens which is not coming from our end,

and it does not present on the front-end since WordPress removes it, if that makes sense.

I hope this helps.