End Transmission

The other day I got some interesting questions about the first Foundation post, so rather than answering them as a comment, I figured it would be more useful to write another post instead.

Read the rest of this entry »

There are a number of reasons why clearing your page cache can be necessary, mostly during a development cycle where you’re repeatedly publishing out the same pages, or need a site wide change to take place. Normally this isn’t a proble, thanks to the nice “Clear page cache” button.

But sometimes it all becomes horribly stuck, timing out rather than deleting any files. In cases like this you’ll need to manually delete the cache. To do this you’ll need remote desktop access to your CMS server.

Go to your reddot installation folder (in our case D:\Reddot)

[installation folder]\CMS\ASP\PageCache\[Project Guid]

In here you’ll see lots of folders with long, unhelpful names. These are the GUIDs of your projects. To get the correct GUID you will need to go into server manager > Administer Projects and find your project. Once you have clicked onto the project name, select the little i icon at the top of the action menu for the actual project Guid. If you try and find this from within the project itself, you get some other mysterious number; I forget what Reddot said it was now.

 You should now have the correct page cache for manual deletion. If you want to be extra careful, it may be worth your while taking a copy of the files just to be safe

Disclaimer

Please be careful! This is your CMS server you’re messing with here… make doublly sure you’re in the right folder before starting to delete files! I’m not responsible if you go deleting your application folders instead of the page cache, sorry.

No-one seems to be able to give us a straight answer for this question. Reddot are suitably vague and other agencies we’ve spoken to all have their own preferences for when to use it… so this is what we’ve worked out over time.

What is a language variant?

A language variant is a copy of your site, within the same project. You can have different users, publication targets and workflows for the different language variants. This would, logically, lead you to believe you can also have slightly different project structures… sadly not.

When should I use a language variant?

The language variants, as far as we can see, are only really suitable for when you want a direct, page for page translation of a site. The business should have signed over their first born child to say they will never change the structure of one variant without making the same change throughout all the other variants.

When should I avoid using a language variant?

As far as we can see… any time you’re not 100% certain that the translated site will have the same structure. Even then we’re not too convinced that the business units always understand this.

What’s the problem with language variants that you hate them so?

Basically there were some rather odd choices made during the development of language variants. If you delete a page from one variant it will helpfully ask which other variants (if any) you want to also remove the page from; this is good. On the other hand, if you disconnect a page it unhelpfully goes through and disconnects if from every other variant without asking. Your editors have to be ever so careful they don’t go breaking any of the other sites!

We’ve had too many issues trying to use language variants, to the extent that the editors came to us and asked for it to be their own projects.

If anyone has any more information on how to best use a language variant, I’d be grateful