Yeh, guess I need to push v0.5 out for production for 7.5+ installs..

v0.5 is now available, changelog includes:


If you need an update (and qualify for updates (within 1 year of purchasing your license) please feel free to email me at james[at]virtualnightclub[dot]net. If it's been past a year since you purchased the script, you can renew at here

Hey Gizzy, I may have asked this years ago, but does this ping google, etc. when a new post is made or a new topic?

No, but I've actually found that Google (and some others) will re-check the sitemap periodically on their own.

Starting this week, I will be working on v0.6 of the UBB.Sitemaps script. There will be several updates to the script that I've wanted to push out for some time and these features will be relating to the speed at which the script works.

I'll be adding options for:
1. GZip - Compressing the output of the file so that it is loaded faster by clients (Search Engines in this case).
2. Caching - Using an in-house script and not the UBB's code (as this script works as a standalone for compatibility reasons we don't rely on UBB code within the script). By default this will be set to 24 hours.
3. Expires Header - This will be another method that will allow clients to retrieve content only when you specify it is going to be new. By default this will be set to 24 hours.

Some of these items will not function with all servers; your provider will need to allow you to:
1. Write flat files via the webserver; some of these files may end up belonging to your webserver user, but will overwrite themselves when needed.
2. Use GZip to compress files.

You'll likely need to play with settings to ensure compatibility but if you can use gzip within the UBB you should be able to use it within the sitemap script.

I'll also be policing for some general code cleanup opportunities within the script as well; I'd highly recommend an upgrade for the new caching options to all users as it'll increase the speed of the script exponentially (especially if you're using the "one big file" method vs the "sitemap index" method (default)).

I'm unsure as to a specific date that the new version will be available however I'll announce here when it's available.

Please also note, if it's been longer than a year since you purchased a license of the script, you'll need to renew your license; you can do so via the information page.

I actually got most of the coding done this morning since I couldn't sleep; I need to finish some of the "new code cleanup" though

Going on track for testing of all systems for release tomorrow; going to go ahead and do a couple of final minute updates to the script tonight and package it up.

For those of you who've registered for the script within the last year (365 days) email me directly for an update (james[at]virtualnightclub[dot]net); for those of you who've registered past that please renew here and I'll ship off v0.6 with your payment verification.

Just packaged 0.6 up and sent off the first copies to those in good standing that have requested it.

I have the caching section working on my server if you'd like to try the preview URL (here) note that I've been having some general speed issues with my server as of late so don't mistake any speed issues as an issue with the script (it should actually parse instantly when serving a cached page).

uploaded and seems to be working great so far

Glad to hear it...

Are you using caching on it or just the default?

well, I don't fully understand what caching does for me,so I left it at default.

Well, think of it like this...

You have it set to display in google and yahoo (or other sites), they send one request and the cache is built and the output is displayed. They send another request, and instead of rebuilding all data from the database (which can be intensive) it just reads out the cached file (until the cache expires).

Basically, makes it so unnecessary hits are dealt with in a manner as to not bog down system resources.

ok, so I enabled caching. :-)

Gizmo,

I have a question about the urls that are included in the sitemap being different from the ones that a search engine might discover on their own.

Could I be penalized by Google for having different links going to the same page?

for example:

Forum link (w/ SE friendly urls & .html extension):
mysite/forums/ubbthreads.php/topics/189951/1.html

Sitemap link to same page:
mysite/forums/ubbthreads.php?ubb=showflat&Number=189951

What do you think? (or did I do something wrong?)

Bill

You won't be penalized anymore than you would if they crawled the UBB and found the URLs on their own; the script feeds them a URL and their crawler will hit pages that are linked off of that page itself to build its real index.

If you follow the example in the readme on what to give google it should actually build the URL the same as what you posted (as form link); the sitemap can be customized to build just about any format of url in just about any type of sitemap you'd want. The recommendation however is to build the sitemap as:
ubb.sitemap.php?type=1&se=2&offset=0

Which will build links as:
http://www.yoursite.tld/forum/ubbthreads.php?ubb=showflat&Number=49643

You could use:
ubb.sitemap.php?type=1&se=1&offset=0

Which would build links as:
http://www.yoursite.tld/forum/ubbthreads.php/ubb/showflat/Number/49644

Currently we don't have an option to build with SEO urls or the fake html extension; we just have se friendly urls and standard urls (which likely will change in the future).

The script primarily aids SE's by feeding content urls to the SE, it'll continue to crawl URLs as it finds them (specifically on links you feed to them), it'll build "new page" links and other links off of the pages your sitemap feeds into their systems.

What I'd like to see is possibly have the ubb gracefully forward URLs with a redirect (301/302 header) based on what URL schema the user chooses in the UBB we could eliminate duplicate urls alltogether (as any url accessed that wasn't on the default selected would send a redirect like what the redirector scripts do); but I'm unsure as to how easy/difficult that could be.