Resolved - X'd out Document Still Shows in Sitemap

[Dirty Butter]

I have a test document that I do not want to use currently, so it is x'd out and not set to be hidden, either. But I discovered via Google Webmaster Tools that it is still showing up in the Sitemap. This appears to be a bug, but as buggy as the reporting system has been of late - and the fact that they don't seem to be resolving anything that's reported to them - I wonder if anyone can suggest a solution to this issue.

I've tested, and this happens in the stock 5.1.5 store, as well as the Fusion 5.1.4 store.

[bsmither]

In the file /classes/seo.class.php, near line 650, find:

$queryArray = array(

'category' => $GLOBALS['db']->select('CubeCart_category', array('cat_id'), array('status' => '1')),

'product' => $GLOBALS['db']->select('CubeCart_inventory', array('product_id', 'updated'), array('status' => '1')),

'document' => $GLOBALS['db']->select('CubeCart_documents', array('doc_id'), array('doc_parent_id' => '0')),

);

Replace the 'document' statement with this:

'document' => $GLOBALS['db']->select('CubeCart_documents', array('doc_id'), array('doc_parent_id' => '0', 'status' => '1')),

The parameter 'doc_parent_id' => '0' means there will not be included any document that rightfully belongs as a child of another document. I haven't studied how that relationship happens.

[Dirty Butter]

Sorry. That didn't fix it. I just did a Sitemap Rebuild, and it's still there.

[Dirty Butter]

While I was waiting for you to have time to reply I tried 2 different changes, rebuilding sitemap each time and then checking to see if the x'd out document showed up - which it did both times.

I tried

'document' => $GLOBALS['db']->select('CubeCart_documents', array('doc_id'),array('doc_parent_id' => '0', array('status' => '1')),

and

'document' => $GLOBALS['db']->select('CubeCart_documents', array('doc_id'), array('status' => '1')),

[bsmither]

The first trial won't work. It's not configured correctly.

The second trial should have included any document as long as its Status has the green check.

Please view the CC_documents table directly and determine if the document you do not want included has status set to anything other than 1.

And by "showed up", let's make sure the sitemap.xml file has the correct or incorrect info. Let's eliminate checking with Google as a variable in these experiments.

[Dirty Butter]

I'm extracting the gzp file and looking at the sitemap.xml file itself, so it's not Google doing it. Checked the database, and it has a status of zero.

[bsmither]

The only thing left to do is double check the edit made to the SEO class, sitemap() function.

[Dirty Butter]

Here's the whole section as it stands now:

$queryArray = array(

'category' => $GLOBALS['db']->select('CubeCart_category', array('cat_id'), array('status' => '1')),

'product' => $GLOBALS['db']->select('CubeCart_inventory', array('product_id', 'updated'), array('status' => '1')),

'document' => $GLOBALS['db']->select('CubeCart_documents', array('doc_id'), array('status' => '1')),



);

I did it the way you said to, didn't I?

[Dirty Butter]

So is there no solution to this but to delete the x'd out document?

[bsmither]

One more test.

In the file /classes/seo.class.php at around line 685, find:

//Ping Google

Four lines down, change $request->send(); to //$request->send(); This stops the experiment from getting sent to Google. We will restore it after the experiment.

Momentarily switch the store to turn off SEO mode.

Create a sitemap.

Re-enable SEO mode and undo the edit to the code.

The new sitemap should now have the standard URLs for the categories, products, and documents. Look at the table CubeCart_documents and compare each line in the sitemap file (the documents group near the bottom) and the doc_id number at the end of the URL with the records in the database table.

You are looking for any document record in the table where status is '0', yet shows up in the sitemap list.

I will say you won't find one.

This is just wild guess, but when you are looking at the database table CC_documents, look for the possibility that you have two documents with different id's, yet have the same, or very nearly the same, title. If this situation exists, then the SEO's "generate the friendly URL" function is creating a reference to a document where it's status is '1', but the title being created suggests a different document - the one where the status is '0' - thus some confusion as to why it's appearing in the sitemap.

[Dirty Butter]

This is just wild guess, but when you are looking at the database table CC_documents, look for the possibility that you have two documents with different id's, yet have the same, or very nearly the same, title. If this situation exists, then the SEO's "generate the friendly URL" function is creating a reference to a document where it's status is '1', but the title being created suggests a different document - the one where the status is '0' - thus some confusion as to why it's appearing in the sitemap.

This won't be the case, as I had already saved off the contents of the real x'd out document, deleted it, and created one with test as the title, etc.

I'll give your no SEO suggestion a try and reply as soon as I can.

[bsmither]

You can also work backwards. Note the exact friendly part of the URL (from the sitemap) that you don't want, find that in the CubeCart_seo_urls table, note the item_id for that record, then find the matching doc_id in the CC_documents table. What is the status of that document record?

[Dirty Butter]

I hate to say it, but even without SEO the status zero document is STILL in the sitemap. Trying the backwards suggestion.

No, working backwards again shows the correct ID with status zero.

[bsmither]

This edit (see above):

'document' => $GLOBALS['db']->select('CubeCart_documents', array('doc_id'), array('status' => '1')),

simply cannot return a record unless its status is '1'.

Did you make the edit to both stores? Could you perhaps be working in one store but only having made the edit to the other?

Can you compare the count of document URLs in the sitemap document with the count of records in the CC-documents table?

[Dirty Butter]

I've only been testing in one store and there are 18 records in the database and 18 documents showing in the just re-created SEO sitemap. This is quite a puzzle, as it obviously states equal to or greater than one.

[Dirty Butter]

i just spotted it! The database documents table uses doc_status for that column!!

[bsmither]

Um, no. FYI:

array('status' => '1')

In the array function (this function creates an array-type variable), the => operator means that the key 'status' is associated with the value '1'. It's not a mathematical operator.

When these function arguments are sent to the Database class, Select function, the class converts these arrays to the appropriate phrases in the SQL command. So, from this statement:

select('CubeCart_documents', array('doc_id'), array('status' => '1'))

the resulting command is:

SELECT `doc_id` FROM CubeCart_documents WHERE `status` = '1'

[Dirty Butter]

Well, maybe it shouldn't have, but - That fixed it! Phew! Oh wait, you were talking about my assumption that it was a mathematical expression.

[bsmither]

Ugh! I hate it when there is less than intuitive consistency between similar objects.

[Dirty Butter]

Enough to drive you crazy - I don't know how you manipulate all this code in your head, but you are a sheer genius!! My hat's off to you - without you this forum would be dead in the water. THANK YOU for sticking with it until a solution was found. I'm sorry I hadn't noticed the wording difference earlier.

I'll try my best not to bother you until sometime next year, so I want to wish you and yours a most wonderful and blessed Christmas!

[Dirty Butter]

FYI - This code tweak has been incorporated into the 5.2.2 stock code.