Understanding the new Windows update history experience

Hi all. Stumbled upon this from a news on whatever IT magazine I wandered upon.

Raised eyebrows on seeing the a multi-billion-NET-PROFIT-per-YEAR company not being able to anticipate a smooth transition to a new website engine.

Raised double eyebrows and rolling eyes when seeing that comment about "new CMS engine does not support maintaining old url" (which is not even a true obstacle by the way, webservers be it Apache or Nginx, can do silent and smooth url rewrite although this is certainly more complex than having the engine with all actual data manage it directly).

Wondered what CMS you could use, went to check on actual website if it was the one I though (disclaimer: I'm not a big Microsoft user, so not too familiar with the support website)... Then grinned hard because it was easy for me to check out my wild guess was right on point.

So two things (actually three).

1/ What you did was damaging for your community, and it clearly feels as a "Microsoft-centered first" change.

Not that it's anything new from my experience as a Microsoft Windows user, but that's another topic. XD

It is however very nice to see you acknowledge the problem at least, and are apparently looking for ways to make everyone happy (which is why I decided to create an account and contribute).

2/ Putting a one-way redirect was a good thing to do but, as everyone stressed, not sufficient.

And while creating url aliases that use "human words" is a good practice "in general", for a technical centric content database, it may not actually be the best move. Reasons behind such urls are "making easier for search engines to index and properly reference them" (still right here), making browsing easier for users (missed mark here: urls are often too long since generated from a lengthy oneliner).

I may be wrong (although I think not) in asserting that you can perfectly serve the same content under several urls without suffering penalties on SEO by clarifying to search engines that one is the canonical ("true") page while others are just "mirrors".

And I don't see why you would stop providing that way to browse updates content either. I mean, you necessarily had to keep that "KB id" information for all content in your new system, in order to set the oneway redirects (unless you made a separate handcrafted list? I cannot even envision that). So you necessarily have a field in which to continue storing the information for new contents. And you necessarily also still have the logic behind id generation, even if it's not (yet?) implemented on your website.

So you have the "datastore", the "id generation" logic, you just have to make your CMS use and expose them. Big deal? I don't think so. 🙂

3/ Fun fact: both operations you say are unsupported by your CMS aka a) providing "old way" to browse support content and b) "stamp the date upon publish" (which I guess is not just "update timestamp of last change" but "add a timestamp whenever the KB is updated on a stack historizing all updates")... Are both largely doable (just probably not from interface alone, that is true). Because I "know" the CMS you use.

In its latest iteration probably (I hope for you ^^). And no, I didn't do anything intrusive at all. I just know most of the times when a site is *-powered because many things in the global look and feel, navigation structure and html/css trees are so similar from one to another. So I'm 99% sure of myself. Any webdev with a bit of experience with the main competitors in the CMS ecosystem could do the same. 🙂

So, for the easiest thing: "provide a way for users to browse update informations with the old url system".

Two things: a) provide a way to browse with that url pattern, b) ensure a KB id is provided for new contents

I guess your "content" has been configured to use its "title" and "uuid" to generate those urls? But you must have another field that stores your internal KB identifier, let's call it 'kbi'.

For a), your devs must simply create a custom route with the old url structure, with a parameter, requiring that this parameter respects a specific pattern. Then associate that with a code that will simply fetch the content matching the provided KB, and "render" (display) it directly, or redirect to the "true" url.

For b), your devs simply have to...

- first, somewhere in their custom code, write the algorithm that generates the new KB.

- second, use something the engine provides to, just before a new content is saved, compute and set the value in your kbi field.

For the other thing, "stamp the publishing date", I'm not sure I understand the actual need (since, as said, I'm not familiar with MS updates), but if it's just about "expose to end-users some dates where the update has been modified" while it's certainly not doable from interface it shouldn't be too much trouble to do from code as well.

I refrained from publishing any example code or providing more precise indications here because I don't know if that would be appreciated, but I would gladly provide some on a more private channel if you would like. I of course have no actual idea on how your organized your data, but from an external point of view it should not represent a great deal of effort to make it work.

Good continuation to you. 🙂

Best regards,

    Laurent