/Commmunity 404s and documentation

[amye]

With the new website, we're able to track 404s a lot better, and I'm seeing a ton of hits for old /community documentation that's not been redirected properly. This issue is to track progress to resolve these 404s: either by making a choice to redirect to docs.gluster.org, move content into docs.gluster.org, or something else that I haven't thought of yet.

[quaid]

I've heard from @amye there are some specific pieces of content she wants to retrieve from the aether and recreate them in the new platform.

Would it be best to have an individual ticket for each item?

What are the details of the current one(s) you are looking at?

Including @mscherer ...

[mscherer]

We have the old website on http://oldwww.gluster.org, and the old blog on http://oldblog.gluster.org/ (I did foresee this would be useful: ( https://github.com/gluster/gluster.org_ansible_configuration/commit/f3c678609501b02220f542813a13f0412d2aad83 ). That's just for reference, since the blog css is broken (but someone with access on the old blog admin interface can fix it)

I also have some old backups of mediawiki but that would requires a bit more work to be reinstalled, provided we didn't clean the db in the mean time. The last bug i found on that https://bugzilla.redhat.com/show_bug.cgi?id=1359062 say that I did a backup, and it is still here.

So I guess I just have to reverse the change and be done with it, but I would first make sure this is useful before working on that.

[mscherer]

Also for reference, I found some stats regarding 404 on the wiki migration 1 year ago:

https://bugzilla.redhat.com/show_bug.cgi?id=1367588

But the data is kinda stale, so maybe we can compare to the existing 404 now to see which one matter and which don't. I suspect the ones we had were just due to Google cache intertia, but maybe a few did survive because there is existing links to fix somewhere.

[mscherer]

As @amye notified me by email, the url for the blog was redirecting to the new website, so I fixed the domain with the following query:

update wp_options set option_value = 'http://oldblog.gluster.org' where option_name = 'siteurl';

(on the 'wordpressdb' on the mysql server from supercolony)

[mscherer]

So while the domain is fixed, the search on the blog seems to use a older vhost community.gluster.org. I am restoring this one too.

[mscherer]

Seems the search was broken since a long time, since that's not working even with the vhost change.

And to answer @quaid question, having a bit more information (like the list of 404) would help to know how long it take, how difficult it would be to find each missing piece of content and so if we need different ticket, or if 1 ticket would be enough.

Right now, i am shooting in the dark, and the lack of information and feedback is not very helpful.

[mscherer]

Due to https://blog.ircmaxell.com/2017/10/disclosure-wordpress-wpdb-sql-injection-technical.html , I locked the old wordpress blog again, as I do not have time right now to dig and evaluate the risk, and do not plan to spend time upgrading a legacy installation. Ping me offline (or another admin with access to the private ansible repo) for the password/user.