SitemapXML v.2

Hello,

i just installed the latest version of Sitemap XML, but when i go to tools/ Sitemap XML i only see an empty page with one button "upgrade SitemapXML SQL"
When i push this nothings happens and i don't get anything else.
Ant idea what to do to make this works?

KGL Racing:

Hello,

i just installed the latest version of Sitemap XML, but when i go to tools/ Sitemap XML i only see an empty page with one button "upgrade SitemapXML SQL"
When i push this nothings happens and i don't get anything else.
Ant idea what to do to make this works?

see the fix for this in comment #1800 (page 180) https://www.zen-cart.com/showthread.php?126810-SitemapXML-v-2&p=1330192#post1330192

cheers,
Mike

shags38:

see the fix for this in comment #1800 (page 180) https://www.zen-cart.com/showthread.php?126810-SitemapXML-v-2&p=1330192#post1330192

cheers,
Mike

Great mike, this works for me!

v1.5.5f PHP7.1 using plugin version 3.9.2

I am using Ultimate SEO URL's (USU) however sitemap(s) are being submitted as standard ZC urls (cPath?) - **the issue is that sitemap submissions are NOT BEING INDEXED ** ... (5 sites)

I still have one site as v1.5.1 using a previous version of this plugin and the sitemaps are submitted using USU and submitted pages are being indexed.

Configuration settings for the old v1.5.1 and the newer 1.5.5f sites are the same in both admin/configuration/sitemapxml and /usu (I cannot see anything different) so I am stumped as to why the USU urls are not being submitted.

.... and yes I have seen a decline in SERP's rankings since the sites were upgraded to v1.5.5f with this sitemap problem. Yes Google is still finding pages and indexing them BUT not all of them and not as regularly as the CRON requests because the sitemap generated is using ZC standard urls - Google's response to all of the submitted url's is 'URL is not on Google - This page is not in the index, but not because of an error'. (see image)

IMAGES ARE NOT BEING INDEXED because the image submitted is for a product page that Google does not recognize!

I look forward to some assistance with this please. (it is more than likely I have done something wrong or not done something correctly).

many thanks,
Mike

[Attachment no longer available]

I found that my long-installed sitemapxml admin page was showing correctly on my hosting but showing only the upgrade button on my local development site.

I find in:
YOUR_Admin\sitemapxml.php
line 255:

elseif (SITEMAPXML_VERSION_CURRENT != $current_version) {

This is finding that $current_version is indeed not equal to SITEMAPXML_VERSION_CURRENT.
SITEMAPXML_VERSION_CURRENT is a created constant made up from
SITEMAPXML_VERSION which is in the database from the last installation, and
_CURRENT is appended to represent this current state/before any upgrade.

Now the variable $current_version is set in
YOUR_ADMIN/includes/init_includes/init_sitemapxml.php

where it parses the names of the installer files in
YOUR_ADMIN\includes\installers\sitemapxml
to end up with 3.9.5 for the latest version of the installer.

I find that on my hosting
$current_version = 3.9.5, so that works ok.

I find that on my dev server
$current_version = 2.1.3, so that does NOT work and prompts for the upgrade.

Why?...because zen colorbox is installed and in

YOUR ADMIN/includes/init_includes/init_zcb_config.php
it also sets a variable with the same name of $current_version, which is 2.1.3, and so this value gets used.

So why does this variable get used differently on my dev server (windows, php 7.1.23) to my hosting (linux, php 7.1.23)?
Files and database are identical.

Answers not on a postcard please!!

Note that the quick fix has already been posted here
https://www.zen-cart.com/showthread.php?126810-SitemapXML-v-2&p=1330192#post1330192
but the underlying problem needs to be resolved.

torvista:

I found that my long-installed sitemapxml admin page was showing correctly on my hosting but showing only the upgrade button on my local development site.

I find in:
YOUR_Admin\sitemapxml.php
line 255:

elseif (SITEMAPXML_VERSION_CURRENT != $current_version) {

> This is finding that $current_version is indeed not equal to SITEMAPXML_VERSION_CURRENT. 
> SITEMAPXML_VERSION_CURRENT is a created constant made up from 
> SITEMAPXML_VERSION which is in the database from the last installation, and 
> _CURRENT is appended to represent this current state/before any upgrade.
> 
> Now the variable $current_version is set in
> YOUR_ADMIN/includes/init_includes/init_sitemapxml.php 
> 
> where it parses the names of the installer files in 
> YOUR_ADMIN\includes\installers\sitemapxml
> to end up with 3.9.5 for the latest version of the installer.
> 
> I find that on my hosting 
> $current_version = 3.9.5, so that works ok.
> 
> I find that on my dev server
> $current_version = 2.1.3, so that does NOT work and prompts for the upgrade.
> 
> Why?...because zen colorbox is installed and in
> 
> YOUR ADMIN/includes/init_includes/init_zcb_config.php
> it also sets a variable with the same name of $current_version, which is 2.1.3, and so this value gets used.
> 
> So why does this variable get used differently on my dev server (windows, php 7.1.23) to my hosting (linux, php 7.1.23)?
> Files and database are identical.
> 
> Answers not on a postcard please!!
> 
> Note that the quick fix has already been posted here
> <https://www.zen-cart.com/showthread.php?126810-SitemapXML-v-2&p=1330192#post1330192>
> but the underlying problem needs to be resolved.
Colorbox (and a few other plugins) uses an auto-installer plugin to locally define and use $current_version in the file it is defined. Can think of a few different ways to address this issue. All plugins that use that auto-installer could be modified to use an additional factor to provide a unique "current_version" variable for each plugin (increasing the number of variables defined in the system intended to be used only locally. A test and storage of an existing value of $current_version could be made coming into each of those to be restored at exit. This plugin could do something similar of uniquely defining the variable or obtaining it locally so that no other definition would interfere.

As to why things work one way on one system as compared to another, it has been posted elsewhere in the forum that the sequence of file loading can be alphabetic or reverse alphabetic if not mistaken. The alternate sequence may be something else, but basically on the live server the sequence of loading supports sustaining the value of $current_version as defined to support sitemapXML, but in the other it doesn't.

the sequence of file loading can be alphabetic or reverse alphabetic
Can you find that? I couldn't. I don't like not getting to the bottom of odd stuff like this.
It is not an isolated case, as seen by others reporting it previously, so warrants further investigation.

torvista:

Can you find that? I couldn't. I don't like not getting to the bottom of odd stuff like this.
It is not an isolated case, as seen by others reporting it previously, so warrants further investigation.

While there may still be a forum post about it, I was able to recall that it is a topic of discussion (issue) in the github for ZC: https://github.com/zencart/zencart/issues/1228. As outlined there it appears that at least for one set of sampling the date/time of placement to the system has an effect. As outlined in the writeup, the associated system dictates the sequence when the "problem" function is used.

I find that the $autoLoadConfig is 999 for both the init_ scripts. Setting colorbox to 998 and sitemap to 999 resolves the problem.
I note that the init_ installer scripts seem to have some commonality, but are not the same.

I think that this problem of different results due to different environments is maybe related to this autoloader issue:
https://github.com/zencart/zencart/issues/1228

millsii:

I had the same problem. I checked, and double checked that all the files had been uploaded correctly.

I resolved it by doing the following:

admin/includes/modules/sitemapxml_install.php

Uncommented line 14 and changed the version number to 3.9.5
$current_version = '3.9.5';

Pressing the "Upgrade SitemapXML SQL" button again resulted in the options page now displaying correctly.
Had exactly the same issue on Zencart 1.5.5f new installation using PHP7 ... The above resolved the problem, thanks for posting

mc12345678:

While there may still be a forum post about it, I was able to recall that it is a topic of discussion (issue) in the github for ZC: https://github.com/zencart/zencart/issues/1228. As outlined there it appears that at least for one set of sampling the date/time of placement to the system has an effect. As outlined in the writeup, the associated system dictates the sequence when the "problem" function is used.

Hello mc - any chance of a response to post #1906 immediately before torvista's post - appears to have been missed?

cheers,
Mike

Remember to change the post title to reflect the content.

When you say "images are not being submitted"...in the various files that sitemapxml creates, in which one are the image links defined?

shags38:

v1.5.5f PHP7.1 using plugin version 3.9.2

I am using Ultimate SEO URL's (USU) however sitemap(s) are being submitted as standard ZC urls (cPath?) - **the issue is that sitemap submissions are NOT BEING INDEXED ** ... (5 sites)

I still have one site as v1.5.1 using a previous version of this plugin and the sitemaps are submitted using USU and submitted pages are being indexed.

Configuration settings for the old v1.5.1 and the newer 1.5.5f sites are the same in both admin/configuration/sitemapxml and /usu (I cannot see anything different) so I am stumped as to why the USU urls are not being submitted.

.... and yes I have seen a decline in SERP's rankings since the sites were upgraded to v1.5.5f with this sitemap problem. Yes Google is still finding pages and indexing them BUT not all of them and not as regularly as the CRON requests because the sitemap generated is using ZC standard urls - Google's response to all of the submitted url's is 'URL is not on Google - This page is not in the index, but not because of an error'. (see image)

IMAGES ARE NOT BEING INDEXED because the image submitted is for a product page that Google does not recognize!

I look forward to some assistance with this please. (it is more than likely I have done something wrong or not done something correctly).

many thanks,
Mike

[Attachment no longer available]

shags38:

Hello mc - any chance of a response to post #1906 immediately before torvista's post - appears to have been missed?

cheers,
Mike
So, I didn't "miss" it, but haven't dived into the inner workings of USU in a while. I do know that one change between earlier versions of ZC and ZC 1.5.5 was to add in a notifier in the html_output functions file that as described was pretty much specifically added to support USU (though another URI rewriter has been able to successfully access and use it as well). At any rate, it would seem that in the "load" process of generating the new URIs for the images (and perhaps product as well) that the zen_href_link response is not accounting for the rewrites. I would guess that it is related to that function. Could be a load sequence issue of the observer for the notifier, though Torvista has pointed out that SitemapXML uses a sequence number of 999 which is pretty high.

mc12345678:

So, I didn't "miss" it, but haven't dived into the inner workings of USU in a while. I do know that one change between earlier versions of ZC and ZC 1.5.5 was to add in a notifier in the html_output functions file that as described was pretty much specifically added to support USU (though another URI rewriter has been able to successfully access and use it as well). At any rate, it would seem that in the "load" process of generating the new URIs for the images (and perhaps product as well) that the zen_href_link response is not accounting for the rewrites. I would guess that it is related to that function. Could be a load sequence issue of the observer for the notifier, though Torvista has pointed out that SitemapXML uses a sequence number of 999 which is pretty high.

MC - I didn't think you had missed it but my post of 14 Nov in here had not been responded to (until just now, by torvista) so I wondered if I was being ignored :smile:

So is it possible to obviate this loader such that the USU / Sitemap function works as it did before the introduction of the loader .... as a temporary measure until there is a workable resolution?

This is adversely affecting how Google is seeing my sites and hence affecting rankings - this is borne out by WMT statistics showing average ranking prior to the 1.5.5f upgrade and subsequently, approximately 3 months now (leading into and now during the busiest sales period of the year and our sales are reflecting it also).

I am not looking for miracles or special treatment but a temporary fix would be good for the hip pocket - I am sure there have to be many others also in the same boat. :smile:

cheers,
Mike

torvista:

Remember to change the post title to reflect the content.

When you say "images are not being submitted"...in the various files that sitemapxml creates, in which one are the image links defined?

Hello torvista,

Only 1 of 6 sites is not submitting images in the sitemap - in sitemapproducts which is where images are submitted in the sitemaps on my other sites. It is likely a mis-configuration which I will investigate further and then report back.

The bigger issue - Refer to my post #1915 - due to this issue the images are not being crawled and indexed via the sitemap because the product page doesn't exist as far as Google is concerned - hence the bigger issue - see mc123456789 response to this - do you maybe have a workaround for it?

cheers,
Mike

here are some myDEBUG logs that may or may not be related to the issue I am having - needless to say I do not know what they mean and hence cannot fix them without help.

from site harmonyballpendant.com

[29-Nov-2018 00:00:11 Australia/Melbourne] Request URI: /index.php?main_page=sitemapxml\&rebuild=yes\&ping=yes, IP address: 223.130.27.110
#1  mysqli_free_result() called at [/home/harmony3/public_html/includes/modules/pages/sitemapxml/sitemapxml_products.php:122]
#2  include(/home/harmony3/public_html/includes/modules/pages/sitemapxml/sitemapxml_products.php) called at [/home/harmony3/public_html/includes/templates/template_default/sitemapxml/tpl_main_page.php:21]
#3  require(/home/harmony3/public_html/includes/templates/template_default/sitemapxml/tpl_main_page.php) called at [/home/harmony3/public_html/index.php:97]

[29-Nov-2018 00:00:11 Australia/Melbourne] PHP Warning:  mysqli_free_result() expects parameter 1 to be mysqli_result, null given in /home/harmony3/public_html/includes/modules/pages/sitemapxml/sitemapxml_products.php on line 122

from site cliponearrings.net.au and harmonyball.net.au - not sure if it is relevant to sitemap or not?

[27-Nov-2018 13:34:28 Australia/Melbourne] Request URI: /dazzlers/product.php?page=17&product_type=1&cPath=1&pID=178&action=new_product, IP address: 61.68.101.120
#1  mkdir() called at [/home/cliponearrings/public_html/includes/classes/usu.php:1604]
#2  usu->__destruct()

[27-Nov-2018 13:34:28 Australia/Melbourne] PHP Warning:  mkdir(): Invalid path in /home/cliponearrings/public_html/includes/classes/usu.php on line 1604
[27-Nov-2018 13:34:28 Australia/Melbourne] Request URI: /dazzlers/product.php?page=17&product_type=1&cPath=1&pID=178&action=new_product, IP address: 61.68.101.120
#1  fclose() called at [/home/cliponearrings/public_html/includes/classes/usu.php:1618]
#2  usu->__destruct()

[27-Nov-2018 13:34:28 Australia/Melbourne] PHP Warning:  fclose() expects parameter 1 to be resource, null given in /home/cliponearrings/public_html/includes/classes/usu.php on line 1618

sitemapproducts which is where images are submitted

In my sitemapproducts.xml, my links as as this:

<url> <loc>https://MYSHOP/manufacturers/acumen/horn-chrome?language=en</loc> <lastmod>2018-08-13</lastmod> <changefreq>weekly</changefreq> <priority>0.5</priority> </url>

No mention of images.

torvista:

In my sitemapproducts.xml, my links as as this:

No mention of images.

see screenshot of sitemapproducts.xml - this is consistent with all of my sites except one as previously mentioned - note product url is standard ZC cPath and not USU - hence the images do not get indexed even though they are submitted

[Attachment no longer available]

shags38:

here are some myDEBUG logs that may or may not be related to the issue I am having - needless to say I do not know what they mean and hence cannot fix them without help.

from site harmonyballpendant.com

[29-Nov-2018 00:00:11 Australia/Melbourne] Request URI: /index.php?main_page=sitemapxml&rebuild=yes&ping=yes, IP address: 223.130.27.110
#1 mysqli_free_result() called at [/home/harmony3/public_html/includes/modules/pages/sitemapxml/sitemapxml_products.php:122]
#2 include(/home/harmony3/public_html/includes/modules/pages/sitemapxml/sitemapxml_products.php) called at [/home/harmony3/public_html/includes/templates/template_default/sitemapxml/tpl_main_page.php:21]
#3 require(/home/harmony3/public_html/includes/templates/template_default/sitemapxml/tpl_main_page.php) called at [/home/harmony3/public_html/index.php:97]

[29-Nov-2018 00:00:11 Australia/Melbourne] PHP Warning: mysqli_free_result() expects parameter 1 to be mysqli_result, null given in /home/harmony3/public_html/includes/modules/pages/sitemapxml/sitemapxml_products.php on line 122

> 
> from site cliponearrings.net.au and harmonyball.net.au - not sure if it is relevant to sitemap or not?
> ```
[27-Nov-2018 13:34:28 Australia/Melbourne] Request URI: /dazzlers/product.php?page=17&product_type=1&cPath=1&pID=178&action=new_product, IP address: 61.68.101.120
#1  mkdir() called at [/home/cliponearrings/public_html/includes/classes/usu.php:1604]
#2  usu->__destruct()

[27-Nov-2018 13:34:28 Australia/Melbourne] PHP Warning:  mkdir(): Invalid path in /home/cliponearrings/public_html/includes/classes/usu.php on line 1604
[27-Nov-2018 13:34:28 Australia/Melbourne] Request URI: /dazzlers/product.php?page=17&product_type=1&cPath=1&pID=178&action=new_product, IP address: 61.68.101.120
#1  fclose() called at [/home/cliponearrings/public_html/includes/classes/usu.php:1618]
#2  usu->__destruct()

[27-Nov-2018 13:34:28 Australia/Melbourne] PHP Warning:  fclose() expects parameter 1 to be resource, null given in /home/cliponearrings/public_html/includes/classes/usu.php on line 1618

For the first issue, which does directly relate to this plugin (don't know the overall affect), a link providing a resolution was provided two pages back and was again found by searching this thread on mysqli_free_result(). See this post for solution: https://www.zen-cart.com/showthread.php?126810-SitemapXML-v-2&p=1339806#post1339806

mc12345678:

For the first issue, which does directly relate to this plugin (don't know the overall affect), a link providing a resolution was provided two pages back and was again found by searching this thread on mysqli_free_result(). See this post for solution: https://www.zen-cart.com/showthread.php?126810-SitemapXML-v-2&p=1339806#post1339806

Thanks mc - I had made that change but only the first suggestion - so have changed it to include the second option - will see if that solves the log problem.

thanks again,
Mike