SitemapXML v.2

[mc12345678]

@mc
I downloaded the zen-cart-sitemap.xml 158 zip from your repository from GitHub and when unzipped the files I get a error Access Denied.

The "Access Denied" message is a little vague. Almost so much so, I don't know of a "simple" question to ask. I've never simply unzipped a file on my local computer to get that message, I've never had a server simply unzip a file to get that message. I have gotten a similar message if I had limited access rights to a Zen Cart site and I tried to access an area to which I thought I had access but didn't.

So I'm a little confused about how simply unzipping the file would necessarily cause an access denied response, unless there is or was more to the story.

[torvista]

Is this a Windows-protecting-you thing...right click on it and see if there is some option to unblock it?

[haredo]

@torvista
Yes you were spot on. My Iobit Malware had my 7zip in the blocked folder.

Thanks for the heads up on finding the culprit.

[neekfenwick]

Brilliant that seems to have worked for me Zencart 1.5.8 Bootstrap V3.5.0 and PHP7.4.. Thanks you

That works for you on Zencart 1.5.8? I'm trying to upgrade from 3.9.3 on zencart 1.5.5, but running into the usual language defines problem. The 3.9.6 release, and the github repo @mc12345678 linked to, contain the old fashioned languages/english/sitemapxml.php file format, but I believe 1.5.8 requires the new lang.sitemapxml.php style with array definitions to be loaded by $languageLoader. I'm attempting a manual conversion, but some bumps in the road, e.g. SITEMAPXML_SITEMAPINDEX_HTTP_LINK is defined and then used in the same file, so you can't define it in an array and use it later in that same array, the way you could when they were define() statements.

Also the menu item seems to have dropped off my Tools menu, apparently my admin_menus database row has page_name 'BOX_TOOLS_SITEMAPXML' and this constant is no longer defined. My old version was zen-cart-sitemap-xml 3.9.3, looks like I'll have to fix up the database menu entries manually to fit the new language define names. I can see that one can invoke the admin/index.php?cmd=sitemapxml&action=install by typing it into the browser address bar to trigger it, but how is it supposed to run otherwise? The 'Install' section in README.md just talks about going to Tools->Sitemap XML which won't appear without the admin_pages / admin_menus database rows.

I've run into this broken admin menu language key problem a few times over the years. Anyone else think it would be helpful to add an else block in admin_access.php zen_get_admin_pages() where it tests "if (defined($row['main_page']) && defined($row['page_name'])) {" so it could log which one was not defined when it fails?

[swguy]

> Anyone else think it would be helpful to add an else block in admin_access.php ...

This has already been done.
https://github.com/zencart/zencart/pull/5412

[torvista]

I believe 1.5.8 requires the new lang.sitemapxml.php style

No. It will load the old-style language defines, and there are no plans to drop that.
Personally I have left all add-ons using the old language defines, to keep them all visually separate from the core files in file listings/comparisons.

[neekfenwick]

>This has already been done.

Thanks for the link, but that's zen_get_menu_titles(), not zen_get_admin_pages() that I was talking about :)

[neekfenwick]

No. It will load the old-style language defines, and there are no plans to drop that.

I must have missed this in my read through the new language system docs. Still a bit blind about the system.

[torvista]

>I must have missed this in my read through the new language system docs

No, maybe you are as stupid as me and just don't understand plain english either:

https://github.com/zencart/documentation/issues/988

[neekfenwick]

No, maybe you are as stupid as me and just don't understand plain english either:

If I understand your point, I think I agree with you, the docs seem to be quite clear that the language file format and loading system was changed, and the old way of using define statements no longer works. There's language to that effect in a few places in the docs you linked indirectly to https://github.com/zencart/documenta...guage_files.md (with use of statements such as "has changed", "will no longer work" etc) .. I don't think it's unreasonable to assume that any old `languages/<lang>/file.php` file would be completely ignored under ZC 1.5.8, that was certainly my assumption. If it's actually a hybrid system that supports the old and new ways of loading language strings, it slipped me by completely. We have a pretty complex site with many customised and custom pages plus addons, some of which have become core ZC, some of which haven't been ported to 1.5.8 yet and I've had to do a hack job on, lots to keep track of. Late here, will bash my head against it more tomorrow. Was hoping to go live tomorrow but probably slip another day with other problems raised today.