Pete

I forgot to ask - is there a better way of having a module run when an admin-only page is loaded other than this: <?php if ($page->template != 'admin') { // Do stuff } ?> It's no longer relevant for this module as it now runs before the page data is available, but when I had it in the first version I gave myself a pat on the back for figuring I could check for the admin template like this. I can see how such a check would be good for other modules though so just wondering if there's a better way for checking if we're in the admin.

Thanks ryan - I was a bit worried about the 404 so this is a good solution and something I'll definitely bear in mind for future modules. I enjoy writing these modules as every one teaches me something new about how PW works behind the scenes. I've implemented your suggestions and replaced the file in the first post with the modified version with the new name (if anyone has this installed already, simply uninstall the old module, delete the module file and install the new one). I also implemented caching as you suggested and cached it for an hour (for most sites a day or more would probably be fine, but if you're writing articles or running a blog you want search engines to index your content as soon as possible so that seemed like a good period to set it at thoguh I've no idea how often search engines actually check a sitemap). I agree that there are quite a few potential issues on larger sites and not just because of the sitemap's size. Google doesn't always index everything on larger sites, and I was just reading about how someone tested this by telling Google that things like news posts and forum posts (individual posts, not threads) should on;y be indexed once as they're unlikely to ever change. This apparently frees up the search engine crawlers to check the new content rather than go over the same content each visit. I can see a few places that this would be useful in PW - for example a news section would only need each article to be indexed once (if you ever went back and edited a page, I believe the last modified date would force a re-index) and various other similar examples. There's a good list of tags for sitemaps here: http://support.google.com/webmasters/bin/answer.py?hl=en&answer=183668 and the tag to use would be <changefreq> , however that could get a bit tiresome if you had to have it on every page. A potential solution for a future version of this module would be to have such a field and simply have all child pages inherit the parent value if they don't have one set themselves. Another option as a possible alternative to caching would be to run the module once on the first time the page is called, then only re-generate the sitemap once a page is edited/created/deleted as those are the only three times a change to the sitemap would technically be required. I'll leave it as it is for now though.

I've had some dealings with this before, however not in ProcessWire specifically. I agree with the idea of doing it per-image as I've had the need in the past to watermark exclusive images from computer games mized in with non-exclusive images in articles. You will have a few potential issues with any approach - if it's a light image, you'll want to apply dark text for the watermark, and if it's a dark image you'll want to apply light text. I would suggest an option be that you can watermark using another image (a transparent PNG) as well, but you can have the same issues as above (think I got around this by making my PNg watermark image with white text and a dark shadow so it stands out on all images). There is actually less code involved in placing a transparent image on top of another image as well, though it would be nice to have both options configurable in such a module. Another thing to take into account is that you only want this to be applied to large versions of images on the final page, though I guess it doesn't matter too much if the thumbnail included a tiny watermark (I'd prefer not on a thumbnail on the final page, but not sure how you would get around it as they're generated on the first page render). If you're resizing uploaded images over a certain size too (like I do) then that needs to be taken into account also as the filename has the large size appended to it, though presumably this new filename is easy enough to get hold of. So lots to think about, but I don't know where you would start either

That's actually how I began this module - as a separate template - but then I thought it would be quicker as a module and then there's no need for an actual page or any templates and it's all in one file. Plus I really wanted to have that optional sitemap_ignore field that I'd used in the previous CMS I worked with. I'm glad I did start creating it as a template and page though, else I'd have had more hassle working out why it wasn't outputting XML (I needed to specify that XML was being outputted by using a PHP header).

Here's a list of services you can submit your sitemap to: Google Webmaster Tools Bing Webmaster Tools There used to be a service for Yahoo called Site Explorer that was similar in functionality to the above two services, but it appears that this has now been replaced with Bing's offering. On the bright side it's one less service to sign up to You can also submit to Ask using the following URL (replacing the relevant part with the full URL to your sitemap): http://submissions.ask.com/ping?sitemap=http://www.the URL of your sitemap here.xml Generally I find Google and Bing to be sufficient though, as the other search services seem to trawl their content reasonably quickly and find out about new sites that way sometimes I think.

I missed the XML sitemap generator that I used in a previous CMS so I built my own module to achieve the same functionality. This module outputs an XML sitemap of your site that is readable by Google Webmaster Tools etc. I've generally found that it reduces the time it takes for new sites and pages to be listed in search engines using one in combination with Webmaster Tools etc (since you're specifically telling the service that a new site/new pages exist) so thought I may as well create a module for it. The module ignores any hidden pages and their children, assuming that since you don't want these to be visible on the site then you don't want them to be found via search engines either. It also adds a field called sitemap_ignore that you can add to your templates and exclude specific pages on a per-page basis. Again, this assumes that you wish to ignore that page's children as well. The sitemap is accessible at yoursite.com/sitemap.xml - the module checks to see whether this URL has been called and outputs the sitemap, then does a hard exit before PW gets a chance to output a 404 page. If there's a more elegant way of doing this I'll happily change the code to suit. Feedback and suggestions welcome On a slightly different note, I wanted to call the file XMLSitemap originally so as to be clearer about what it does in the filename, but if you have a module that begins with more than one uppercase letter then a warning containing only the module name is displayed on the Modules page, so I changed it to Sitemap instead which is fine as the description still says what it does. File can be downloaded via GitHub here: https://github.com/N.../zipball/master

It literally runs your code before that process - saving the page in your case.

I think I encountered this one a while ago when I was writing a module that wasn't as optimised as I'd thought at first. Did you install any modules around the same time? Of course, xdebug might be complaining if multiple pages are saved at the same time, as is the case if you re-order pages for example (I think every page on the same level has to have it's position saved so the same functions will be called then and that could be what it's complaining about). I ended up not using xdebug as it was more hassle than it was worth and turned on proper PHP error reporting and put PW into advanced mode in the config to get detailed error messages that way.

Yup - you may well face-palm when you see the copy function ryan posted, but I tend to get confused with this at times too, especially with form input (move_uploaded_file in that case, but you can also use copy in that case as well which confuses me more, even after reading PHP's notes on the move_uploaded_file function).

Just a guess, but do the other fields it's nor parsing contain a colon as well?

No worries - to be honest I didn't even realise it was a GIF until I uploaded it and I'll probably just convert it to a PNG anyway. I think in my code in the past to get around potential headaches with grainy thumbnailed GIFs I saved them as JPEGs instead to get better compression, but that's not always going to be the desired way to do it.

Hi I think there might be a problem when showing thumbnails in the page editor if they have transparent backgrounds (see attached image). Basically when an image is resized I don't think it's storing the transparency data. It's been a while since I looked at thumbnailing in PHP and I think you can save that data when thumbnailing gifs, but an easy solution here would be to set the canvas background to be white instead of black (which I seem to recall is the default) since the page background is normally white in the PW backend. Obviously saving the transparency would be the favourite solution as I know we have one dark admin theme already. Possible solution here: http://www.php.net/manual/en/function.imagecopyresized.php#104556 Not sure if there would be similar issues with PNGs?

It's actually really useful seeing this piece of code develop as I keep forgetting you can chain multiple things together like this. The beauty of this jQuery-inspired way of doing it is that it still remains readable afterwards too

Congratulations on releasing another very useful module so quickly I like this one especially as it's somewhat similar to various forum software solutions for styling post content, but it actually teaches people some HTML instead of dumbing things down, whilst just making some things quicker for the rest of us.

I was thinking that if you have a "Tags" field then it will search all Tags fields on all pages where the field is used and suggest tags as you type as it does on some of the examples on his site. I know it's not particularly simple, but on a per-field basis where you would use this it would be neat to have the ability to tick a box to enable this as I can see places where it would be handy and places where you might not want it. In the tags example it might stop someone adding a tag that's spelled slightly differently by accident or something like that. That's not normally a problem with one author, but could be in a multi-author environment.

Holy crap, this is great and would come in very handy for blogs (which I would guess is what you're using it on ) - does it have an auto-complete option like on Guillermo Rauch's site?

Very nice site! Loads pretty quickly for me too, but if there are complaints about speed you could always look into PW's caching options (if you haven't already). Love the page showing the monthly post stats and the tag cloud as well - I was thinking a few weeks ago how to do a tag cloud and it was pretty easy but I've just not had the need to implement one yet. As with most things in PW it's a case of working out how to do something not if you can do it which is the beauty of the platform. I'm also converting a site from Wordpress to PW but it was only because WP was used for the original site (which isn't actually a blog site), and now the client is happy to move to PW to get away from the seemingly-regular security updates in WP. WP is a well-established platform, don't get me wrong, but surely there can't be that many security issues left to fix by now?

Cool card I too will likely be on and off the computer throughout the holidays so I'll give it a spin as well.

Happy Christmas guys and have a great new year

If there's only one bkgimage for a page you could do something like this: <?php echo $page->bkgimage->first()->url; // or $home = $pages->get("/") ; echo $home->bkgimage->first()->url; ?> Bit simpler. Or if you want to upload multiple images for each page and pick one from random on each page load you can do this: <?php echo $page->bkgimage->getRandom()->url; // or $home = $pages->get("/") ; echo $home->bkgimage->getRandom()->url; ?> For an idea of things you might combine to achieve different results, the Cheatsheet is definitely worth a look if you've not seen it already: http://processwire.com/api/cheatsheet/

Just a guess, but shouldn't it be this for the parent image URL? $page->parent->bkgimage->url As far as I'm aware yoyu can't use $parent - the easiest way to think about it is everything is in relation to the current page you're on, so parent is $page->parent and children are $page->children and the value you're looking for gets appended on the end, so $page->parent->bkimage->url or $page->children->first()->url as a few examples.

What would you like it to do? This page contains a lot of information on the subject here: http://processwire.com/api/templates/ And there's an excellent tutorial by ryan here: http://processwire.com/talk/index.php/topic,755.0.html EDIT: forgot to mention that the files themselves are in the site/templates folder for the default template - you would be looking to work with head.inc, foot.inc, home.php and basic_page.php as your most common files to begin with. Hopefully a combination of the above information will give you a good start

That's the way I'd suggest doing it too - much tidier

Here's my script. I looked through it and it was showing it's age a bit in terms of how scrappy the code was (and the email bit in particular is unnecessarily repeated) but it works and I've commented various lines and made it slightly less horrendous to follow. You'll have to look at the various vars like the paths and database login details and adjust them to suit your site. I then created /home/mysite/backups and inside that backups folder I put the script and folders called "site" and "db". These are all required steps. I keep it outside of the public_html folder - the cron job runs it just fine there and there's no danger of someone being able to download your backups You would then simply set a cron job to run daily at a sensible time to kick off the backup. The script is adapted only slightly from techniques on this very useful website: www.tips-scripts.com To actually get the backups from the server to your PC on a regular basis, I use this program: http://2brightsparks.com/syncback/sbpro-features.html . It's reasonably-priced and you can schedule backups from FTP which does the job. Granted you could also achieve the same in Windows with a .bat file and Windows Scheduler (and I have done in the past) but since I also use this backup program for other stuff (mirroring external hard drives etc) I just do it this way. EDIT: I know there's a bunch of repeated code in there, and thinking about it I've just thought of an excellent way to do this on my VPS so that from the root account it goes through each website in sequence so I only need one copy of the script, but it does give you an idea of what you can do with a few lines of code and the right privileges on your server cronbackup.zip

There will be a way to do it, but I thought I'd just weigh in with the note that if you keep moving published content, you'll hurt your search engine rankings, especially if it's a page that's been indexed for a while. The best thing to do is stick to a structure and not be tempted to move stuff about. That said, if you're only going to move a page once maybe, then a 301 is the best way to go as ryan says. You could even write a little module to edit your .htaccess file and have it append moved pages to the end whenever you move one theoretically, but that's a bit overkill as you shouldn't be moving that many pages that often anyway