New Wiki #48096
Labels
No Label
Meta
Good First Issue
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Eevee & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds, Tests & Devices
Module
Python API
Module
Rendering & Cycles
Module
Sculpt, Paint & Texture
Module
User Interface
Module
VFX & Video
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Information from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
19 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-manual#48096
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Status:
Wiki Migration Plan:
Bake the old wiki as static HTML and place it at https://archive.wiki.blender.org . @TuomoKeskitalo
The baked pages should look as before and links should work. However, editing functionality and mediawiki features such as the chat and special pages will be lost.
Possible approach to do this: http://camwebb.info/blog/2012-12-20/
Make a redirect page for broken links. @brita
Release Notes: Remove the copy of the old Release Notes and make direct links to the archived version. @brita
Add-ons: Make direct links to the archived version. This is a temporary working solution until there is a decision for new system in blender/blender-addons#54097. @brita
Technical Docs: Copy and organize Dev:Doc and Dev:Source @brita It's ongoing work to organize and update the wiki contents. But I consider it to be "ported" by now.
Landing Page: See infrastructure/blender-org#57987 @fsiddi, @brita
Theme @fsiddi
Utilities
Ensure the templates work well with the theme. @brita
Licensing
Delete the old read-only PHP wiki. @dmcgrath
[On hold] until:
it is no longer needed to copy the content source, and there is the static HTML version.
NOTE: The new Wiki is in it's transitional phase atm.
It’s goal is much more limited than previous one, basically this is a
developer/module team members tool to share technical docs. It should
also have general help info like setting up a new build of blender, some
code architecture docs, etc.
Moving a subset of old wiki pages is on-going process.
Old wiki shall be locked (made read-only) in a few weeks, proposed date
is June 15th. That means that developpers (also including GSoC students)
should request accounts on new wiki if they do not have one already, and
move their pages there.
Note that once in read-only state, it will still be possible to access
and copy wiki-markup content of the pages!
Recently Dan set up a fresh install of Media Wiki and migrated the old pages to it. This can be found at https://en.blender.org
To set up an account (developers only) just informally poke a wiki administrator for now
[these are @ideasman42, @brecht, @dr.sybren, @dmcgrath atm]
There are still several todos
Theme
Clean Structure
Excluded from Wiki Migration
There are a couple of sections that mostly contain historic content and it is preferred to not port these over
(but this has to be checked carefully -- if in doubt, ask around... help in these decissions is welcome!)
What still needs to be done
Architecture docs: #61097
Addon catalog/ docs: move to the manual , see blender/blender-addons#54097
Changed status to: 'Open'
Added subscribers: @Blendify, @BrendonMurphy, @Tobias, @ideasman42, @Ton
Added subscriber: @dmcgrath
I don't know that I would go so far as to remove the old 2.4/2.5 manuals that exist in the wiki as they are the only manual that exists for them, unless people feel we could just assume it to be deprecated and removed from existence.
I wonder if it would be better to maybe try doing a one time conversion of the old 2.4 wiki manual back over to sphinx, once we do versioning over there with the manual. At least then we could provide redirects to the manual that would be indexed by Google and searchable/findable by people with old versions of Blender, or people who are merely curious.
As for how to structure and layout the updated wiki, I don't really have any opinion here as I am not the person that edits stuff. If you like using transclusion to create pages, that's up to the editors.
On the topic of a theme, Naiad is currently broken for the navigation tree on the left of the page. Personally I say scrap it; it looked nice but was too coupled (IMHO) to the extensions and templates/transcluded pages etc. I also believe it has problems with mobile? Anyway, I think it to be a terrible design when half the site breaks just be changing to a stock skin, like vector.
I also am curious what others think about the idea of moving to a Wiki family and using interwiki links for languages (eg: fr.blender.org, de.blender.org, pool.blender.org, etc.) for translation of everything else on the wiki, very much like how wikipedia does things.
Ok, I think I have a clearer idea about the whole old wiki version things. We should keep the old manuals but not have wiki version for the rest of the wiki. Here is my idea on how this should be structured.
I don't have a strong opinion on whether the old manuals get moved to sphinx.
Added subscriber: @Genome36
Hello everyone !
Manual theme redesign
Current vogue is in the
materialandflatdesigns.I think the wiki could benefit of efficient space usage just as shown in this image.
A little bit of CSS magic can help change the current wiki remake to be on the same level as:
Manual versions
As far as the old wiki goes; I think we should keep the latest major versions just for retrospective [2.40, 2.50, 2.60, 2.xx ].
There should also be a latest version, updated on the fly.
Added subscriber: @mont29
Thanks a bunch Dan for setting up new wiki! :)
Content
2.4 and 2.5 manuals: those would simply remain readonly, kind of 'archived'. I don’t see much point on wasting time on them to port to sphinx or whatever, but there is no reason to remove them either, they can be 'forgotten' in their own corner imho. :P
In fact, maybe we could have an 'archived' section in the wiki, where we explicitly dump any page which is no more in sync with current blender - would include said manuals, but also all old design and tech docs that are no more really relevant. This way, no need for 'version' name spaces.
Skin
Agree it would be nice to make it coherent with other blender sites, but imho most important thing is to have something easy to maintain and update along with wikimedia. So rather use a well known and maintained skin (even default one?), with a few as possible customization (css-only ;) ).
Naiad was a great result, but trying to make wiki not look like a wiki requires tremendous work - to create it and to keep it working at each update! Let's not forget that wiki, now that manual uses its own stuff, will mostly be tech doc place. We want to keep it simple and easy to use and maintain, more than everything else.
The problems with Naiad is (currently) the Nav tree is missing. The problem with Any of the stock skins is that we have a bunch of Naiad related cruft in the templates that make a stock nav area break, so things need clean up if we want to go that route. It doesn't matter to me either way; I am just letting you know that if we go with a stock setup, there is a lot of work needed to clean things up and bring it back to a stock setup.
+1 for @mont29's reply.
Best we have wiki that can be maintained and not focus too much on customization unless if gives real practical benefits and doesn't prevent us from upgrading in the future.
Added subscriber: @brita
Hi,
Skin:
I have no idea how much work is to setup the new skin, vs stripping down our current version to be compatible with the default skin.
That being said, I am all in favor for css tweaks so that it looks like the other blender websites, as long as it is not too much work.
I am not so worried about styling, but about the functionality of the navigation.
Content:
+1 for read-only versioning. I understand that this means to keep the content as it currently is, with new material going to sphinx.
I think the default skin is better than going back to the old Naiad.
I started to do some cleanup of the current wiki today, mostly in the release notes area, but ran into a problem when trying to delete pages.
Currently, there is no way to batch delete files. I did a simple Google search and found some solutions that might help:
However, there may be a chance that these will not work due to the old media wiki version that we use.
In this case, I think that we should layout a day where shut down the wiki and move to the new wiki.
From here we can use those scripts to delete many pages that we don't need. A big example
here would be the old manual translations (2.4, and 2.5, 2.6).
So this is mainly a question for @dmcgrath on whether the scripts would work or not,
If not we need to get a time frame for when to shut down the wiki and make the new wiki default.
Hi @Blendify,
There is a problem with the current wiki in that we cannot add new extensions. Normally when you add an extension you need to run an upgrade script to extend the database schema, but this script is broken in the current database due to a problem with Latin/UTF problems, so we wouldn't be able to activate new extensions. The problem gets fixed when we upgrade Mediawiki though, so the new system would be able to run these extensions just fine, and I believe are even included in the new site.
It may be possible that I can I run some of the admin scripts in the shell to delete specific urls though. Looking at the shell, I do see a "deleteBatch.php" script. It appears to take a text file with a list of pages to delete:
<listfile> : File with titles to delete, separated by newlinesMaybe this would be enough? Or would you guys rather wait and switch to the new wiki instead?
It seems like you are talking about https://www.mediawiki.org/wiki/Extension:DeleteBatch which was the second bullet point.
No, there are php scripts in the maintenance folder in Mediawiki installs that let you do stuff that may or may not be available through the web UI. The extensions I think are more meant for people without shell access.
Eeeeeeekkkkk!
Where was this ever agreed on? Translations should be handled the same as english manual imho, archived and made non-editable, but why deleted?
Added subscribers: @fsiddi, @brecht
After trying to work on #48381 I found that the current wiki is too slow for me to do anything.
I think the best solution right now is to do a little theme clean up and make the merge to en.wiki.blender.org
After everyone is forced to use en.wiki.b.o pages can be added/removed/moved has needed with a lot more ease.
I have just checked the manual, and there have been performance improvements, so it should be back to normal now.
Added subscriber: @GaiaClary
Hi;
Today i found in the official wiki that vimeo videos seem to be embedded by using the flash video player. I propose to customize or update the plugin so that it uses the html5 player instead. Here is an example page:
https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.78/Physics
When i open this page with firefox, then i get the warning about usage of flash.
I also noticed that it looks like the new wiki does not (yet?) support the tag. I believe it is important to at least support embedding of videos from vimeo and youtube.
Added subscriber: @bdube-1
Added subscriber: @xan2622
Hello.
Is it planned to allow to log in to the (upcoming) new wiki with a developer.blender.org account?
I hope it will be considered because it's not currently possible to log into wiki.blender.org with a developer.blender.org account...
Thanks.
hi,
https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts
could be archived and a new set of pages created for addons.
as one of the original authors and designers of this page and
https://wiki.blender.org/index.php/Extensions:2.4/Py/Scripts
I would be happy to work with wiki devs to see the new pages created for blender 2.8 series.
Added subscriber: @lichtwerk
I was about to update the new wiki, move/copy more stuff from the old wiki, I can log in using the credentials from the old wiki but I dont have editing permissions in the new wiki.
Could somebody set this up for me [or tell me how to do it myself]?
Thx in advance!
The wiki was meant more for testing. There will be no porting over as the actual port work will involve disabling updates to the old site, and then doing a database dump into the new wiki, followed by shutting down the old one and renaming the new one.
I think after the 2.8 release should be a good time for this even if we use the default wiki skin.
Added subscriber: @dr.sybren
I would like to handle this and I want to create a separate design/structure document before we go about that.
Please refer to blender/blender-addons#54097
Added subscriber: @VukGardasevic
Help > Release Loglink will have to be updated after the switch.Added subscriber: @nBurn
I just saw the big wiki changes happened today. Two questions:
Is there more information available as to the reason for the migration to a new wiki? I looked over this thread, but I'm not seeing much in the way of specifics. This would be helpful in a FAQ point of view, in establishing some rough rules/guidelines, and for preventing any perceived negative aspects from the old wiki from creeping into the new one.
Is there more information about what is being migrated over and what isn't? For instance, the old tutorials (e.g. Modeling Two dice)? Templates? User pages? Feature requests / design mockups? Docs on depreciated Blender features (e.g.: Blender Internal)? User add-on docs (for the add-ons not shipped with Blender)? Summer of Code pages for previous years? I'm guessing no for the tutorials and feature requests, but I was not as sure about the other items I listed.
https://wiki.blender.org/index.php/Dev:Doc/Process/Bug_Reports should be migrated, as it does serve some purpose for bug reports.
Added subscriber: @LazyDodo
It's already migrated, you can find it here https://wiki.blender.org/wiki/Process/Bug_Reports
Thanks :)
I find that at the moment the state of the move is a bit messy with a lot of broken links and no visible plan.
@dmcgrath is it possible to rename the old wiki from https:*en.blender.org/ to https:*archive.wiki.blender.org/ ?
This would help make clear for any reader why is that wiki read-only.
Is there any plan with redirects?
Example of links that no longer work:
http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Generic_Distro/CMake (should be on the new wiki)
http://wiki.blender.org/index.php/Dev:Doc/Code_Style (should be on the new wiki)
http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/DataAPI (should be on the old wiki ?)
http://wiki.blender.org/index.php/User:Brita/Configs/VSCode (do I need to move my user space pages manually?)
http://wiki.blender.org/index.php/User:Dfelinto#Git (what about someone else's user space that may or may not still be active?)
I see that there is a redirect from http:*wiki.blender.org/index.php to https:*wiki.blender.org/wiki but then the page is still not there.
Is it possible, in that case, to redirect to https://archive.wiki.blender.org/ ?
Or for every single page to show at the top "This article was also found on the ", with a link?
The old wiki will be destroyed/deleted at some point (have yet to pick an actual date). There is a dump of the files already available now for others to import into their own private MediaWiki installations so that they can retrieve old articles to migrate them to the new wiki. Long story short: there shouldn't be any confusion because nothing should be referencing the old wiki.
Redirects that aren't external to the actual wiki (ie: https://wiki.blender.org/) should be handled in the wiki itself by creating a page at the "broken" location, and then redirecting it to the new location. External URL's would require another MediaWiki extension, so they can be done via the web server redirects.
As I alluded to above, where there is a missing page that needs to exist, it should be copied from the old wiki to the same exact spot in the new wiki, then moved and edited to match the new policy and style guidelines that were decided on. So your personal page(s) you would copy and migrate (or by all means try ask one of the wiki "guru" to possibly bulk migrate your stuff for you, perhaps?) to the new wiki.
Again, the old wiki is a maintenance nightmare (and the whole point of us starting the wiki from scratch) and potential security risk (unmonitored/maintained php code silently being abused on a server). The "archive" is already available at https://download.blender.org/oldwiki/ in a format that any MediaWiki installation should be able to import. If someone feels like spending time to parse out all of the pages into separate wiki markup files, perhaps we could host that in this directory as well. Space isn't a concern, but someone needs to split the files up and provide me a tarball for us to host.
As for the exact cut off date, I'm flexible here, but at some point we really do need to take it offline. Making things read-only doesn't actually protect us. Anyway, I hope this answers a few questions?
Hi @dmcgrath, thank you for the explanations, that made the current situation a lot clearer to me!
I was under the impression that making the old wiki read-only would also protect it from spam & etc, but I see that if it's still old unmaintained php code running on the servers, that's not very good :)
I tried downloading the archive, (which is great to have and reasonably small, so that's great!), but I am not sure what to do with it.
Meaning: I don't think it is reasonable to expect regular people going through all the pain of downloading the archive, unzipping and searching through it after finding a broken link on the web.
I can go through my own user space and manually put it on the new wiki, no problem.
But what's the plan for other people's spaces, old design documents, addons, old manual versions and links that just don't match anymore (like the CMake one above)?
Is it to batch process all of these these pages into the new wiki? Can the new mediawiki installation just import the entire thing?
You mentioned someone should do this, page by page and manually?
Would it be better to try and process original design docs and manual versions into really-read-only-non-php versions?
Or is there some user friendly "viewer" for this xml archive?
Last important question! Who are these wiki "gurus"? :)
(Sorry for all the questions, maybe I missed out on reading something?)
Added subscriber: @greylica
No problem!
Well, having it locked down and read-only prevents modifications and most annoyances, but it's the risk of just leaving an already old and vulnerable app running that concerns me.
Sure we could, in theory, upgrade the old wiki, but it would break the pages horribly, and then I would be stuck maintaining two wikis! Worse, the old one is a horrible mix of multiple svn repos. Originally they had it setup to have an internal (secrets!) and an external (public) svn repo, and would cherry pick commits from one to the other. It was already a headache to maintain, then commits stopped and we have a mess of partially committed changes. I'd rather eat spaghetti, not maintain it :D
Yeah, the files are fine, but the massive xml dump is really something that would need to be processed by py/perl/sed/awk type scripts, or by just importing it into a vanilla wiki. Either way, it's a ton of work! This is why I was really hoping that people would take the migration a little more seriously, because I honestly have a million more important things to do than also migrate the wiki :(
All very good questions! The understanding that I have is: if it's an important page, migrate it; if it's not migrated, then it will (eventually) go to the bit bucket in the sky and all traces of it's existence be forgotten! The exception of course being this "secondary" archive of the page dump.
As for batch processing, yes the process that dumped the pages can also import the pages. Problem is that because they tied all of the page markup into theme code, you can't even get a page to display without our theme, iirc. Still, if you can get the original markup text, you should at least be able to manually salvage a decent amount of content out of what you can get.
Realistically, you would probably want to apt-get install a mediawiki in a VM or something local, import the old pages, and then create a modified manifest of everything you want to keep, then export those pages only for import into the new wiki. Be warned though that the old pages are horribly tied to the old theme and templates! It would be a frustrating experience to bulk migrate it short of copying all the old junk that we decided to remove in the new wiki, and we would be right back to square one: an unmaintainable wiki
I assume you mean a wget or something that is "static" html. This process can work, but then all the old urls and pages get horrible urls. Worse, the search engines will start double indexing stuff, unless you exclude it with robots.txt etc etc. It's all just a headache, tbh. Take a look at archive.blender.org. Then look at the page source!
In all honesty, it's meant to be dumped from mediawiki to xml files, then imported back into mediawiki. But sure, if you have the xml-fu skills, one could slice and dice it all up into something useful. All comes down to how much time one wants to spend sifting through the sand to find the gold nuggets! ;)
Good question :) @greylica and @mont29 were the best (only?) guru's I think we had. I barely know anything about MW myself, which is why I try to stay out of this other than from an admin with the actual access POV. Perhaps someone from #mediawiki or #wikipedia would have sympathy and help out a bit, but we don't have an open system because of the headaches of drive-by spam and lack of moderators. Perhaps we should put out a call for an actual MediaWiki administrator?
No worries! Nice to discuss things for others to get caught up on the situation and some of the difficulties of it all.
Plan for completing the wiki migration:
Old wiki archive
As I understand it, even though the current 'old' wiki is read only, it is still an installation of old php code that is a security hazard.
Can we please make the final html read-only version and put it on the final domain "https://archive.wiki.blender.org/"?
This would allow for pages to explicitly link to the original version of a page or to pages that were not ported.
Broken links
Links that people referenced somewhere or bookmarked should never be broken.
If there is no page for it on the new wiki, I propose that the 404 error page on the new wiki presents a link to the same page on the archived wiki (that may or may not exist).
Something along the lines of:
"The page you are looking for was not found.
Purpose and scope of the new wiki
The new wiki is meant for developers and Blender contributors to talk about Blender technical topics.
It should, therefore, have:
In my view, this leaves out:
The future of these is under discussion on blender/blender-addons#54097. For now, existing links should work.
I propose that release notes for the different Blender versions are kept only in https://www.blender.org/download/releases/
The new wiki can still hold the notes for the version current under works, which allows for collaboration on making the release notes and that's all.
At the moment, the release notes pages were already copied to the new wiki, but there are many problems, such as missing images, templates, broken links, broken structure and bad formatting.
I tried to fix it for a bit, but it's really inglorious work to even check if version 2.49 of Blender looks ok. I think this should be left as it was and the copied pages should be removed.
My proposed points of action:
Added subscriber: @Sergey
Here are some instructions which might help with static-isfying the old wiki: http://camwebb.info/blog/2012-12-20/
This all seems reasonable.
Regarding release notes, it's not entirely clear to me what is being proposed. Once the old wiki is archived to HTML we can redirect to that for old versions, and then afterwards remove the old versions from wiki.blender.org. I'm not sure if anyone will convert the wiki release notes of the current or future releases to blender.org though, that's a lot of work. If we want to have the release notes in another format for future release we better write it in that format directly, otherwise we probably just keep linking to the wiki.
Added subscriber: @brhumphe
One request regarding the new wiki I would like to see: explicit version numbers. The new wiki does not specify which version of Blender the articles are relevant to. Something I appreciate that the Python documentation does and the old wiki does is have a selectable version dropdown menu which allows you to make sure the version of the page you are reading is correct for the version you are working with, and select a different version and be immediately taken to the correct page. I've been hitting a lot of dead links lately trying to figure out which set of build instructions is correct for 2.7, which has been a bit difficult since the old wiki does not have anything labeled 2.7, but the instructions in the new wiki are specific to the latest builds of 2.8.
EDIT: I see that one of the goals of the changes is to remove version numbers and always have it up to date to the latest versions. I suppose I simply disagree with this for the above reasons.
Added subscriber: @pablovazquez
@brhumphe The Blender User Manual does have versioning: https://docs.blender.org/manual/ . But you say compile? That shouldn't really change, it would be nice to have an easier explanation of how to work with branches, but otherwise, I don't think it needs versioning.
@brecht
Regarding release notes, I propose to delete everything under https://wiki.blender.org/wiki/Reference/Release_Notes except for the ones for 2.80.
This is because the copies don't look good and it would be too much work to make it better, without a clear benefit.
Examples:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.49
Compare [an original version ]] with [ https:*wiki.blender.org/wiki/Reference/Release_Notes/2.72 | the copy. -> Images are missing. Click the first link "Cycles Rendering". Images are also missing and links are broken.
I thought that the wiki release notes were already converted to blender.org by @pablovazquez or @fsiddi ?
@brhumphe, the versioning in the old wiki was never actually used for developer docs. The individual history of pages can be used to go back to a specific date, however build instructions are actually identical for master (2.7) and blender2.8 branches.
@brita, wiki release notes don't get converted, there is only a landing page on blender.org that links to the wiki pages. We can delete the release notes on wiki.blender.org once there is a way to redirect to the archive versions of those pages with images, if we delete them right now it breaks a lot of links.
@brecht
I don't know what's the process for the release notes after they're finished on the wiki.
I see an html version on blender.org. For example: https://www.blender.org/download/releases/2-74/
Clicking on a "Read More" indeed links to the wiki.
I experimented with making an explicit redirect, but redirects to an external link require an extension as they are seen as a security risk.
I came up with this instead: https://wiki.blender.org/wiki/Dev:Ref/Release_Notes/2.74/UI
We can either do that, a link that people would need to manually click, or install the extension .
I think the security issue is that anyone could edit a popular page to redirect to their own scam website or so?
We can make it so that only external links to the old wiki domain are allowed. I don't see a security problem with that. @dmcgrath?
It's still a choice if we want an automatic redirect or an intermediate page so that the reader clearly understands that he is going from a beautifully maintained wiki into an archive.
Added subscriber: @TuomoKeskitalo
Hi,
I tried to bake the old wiki as static HTML, but wget is disallowed in robots.txt. Also, it makes sense to run it locally/close to server, so somebody with local access should be able to run the bake command (after modification of robots.txt):
cd archive
wget --recursive --level=10 --page-requisites --adjust-extension --convert-links --no-parent -R "Special" -R "action=" -R "printable=" -R "oldid=" -R "title=Talk:" -R "limit=" "http://en.blender.org/index.php"
After that maybe check if something else listed in http://camwebb.info/blog/2012-12-20/ is still needed.
Hi Tuomo, if the user agent is the only thing breaking your bake command, you can change it:
you can also convince wget to ignore robots.txt with
-e robots=offThanks for advice, seems to work. So, will somebody do it locally, or should I give it a go next weekend?
@TuomoKeskitalo
I gave your command a quick try with
--level=1and it seems to work pretty well! (I don't have local access to the server)Some links are going to the web version, but I think that's because those were excluded from the copy.
I played a bit with the rejection list and it looks possible to keep both the edit page and the history list (without the diffing), both of which are super useful.
I simply omitted -R "action=" , but then there's all sorts of other things to discard, such as "action=delete" and "action=unprotect".
Curiously, some of the rejected expressions didn't work for me. I still see the oldid=*
I wonder how much space do the rejected pages occupy and if it wouldn't be better to simply copy everything.
@dmcgrath
Is it possible to unlock the old wiki for edits before the bake, in order to add a note saying it's the archive (as it was done when the manual was moved)?
The rejection list is mainly to prevent the process from purging all the pages and doing other crazy things. If some of the unwanted pages are getting sneaked in, you can always delete the file.
As for the note, is it possible to ensure all pages have it, without going and editing every single page?
Also, with all those months en.blender.org existed, is it really a place for an archive? Or we do break all the google search links to it once the archive is done?
I think that when the manual was moved, the note was added to namespaces and not per page.
Poking a random page, I see the warning, but not the source for it and also nothing in the history. -> https://en.blender.org/index.php?title=Doc:2.6/Tutorials
I don't know how it was done.
I don't think there should be an "en.blender.org" it has nothing that resembles "archived old wiki" on the title. It's just confusing, and it has been so for many months.
Search engine indexes will recover in another couple months? Hopefully they'll start pointing to the new wiki once that's a bit more composed?
We could put the archive on archive.blender.org/wiki. If needed we can still set en.blender.org to redirect to the new location.
If we need a message on all pages, I can insert some html directly into the php/theme code on the server.
Sorry, I'm not exactly sure what you are asking about here. I am not exactly the best person to ask about MediaWiki features, let alone security related features.
This can be tricky to do with editable wiki docs. What would be your typical use case here? If this is only for building older versions of Blender, one option could be to start packing a copy of the build instructions on the wiki into the Blender source code when it get archived during a release. That way even if a certain build setup gets depreciated or undergoes significant changes, there will still be a instructions available for how the code was compiled without having to dig through the wiki's edit history or hoping there's a backup copy of the instructions somewhere on archive.org .
I don't think it would take that much work to port over what's left of the release notes pages to the new wiki. The main difference between the two URLs you listed is the missing images which should be a quick fix. Any special template formatting should not be a major problem either, just port the old templates to the new wiki or strip out the template formatting. The thing is if the old wiki is left online as static HTML this removes the main reason to port these pages over.
I would recommend keeping the 2.79 docs on the new wiki and not just the 2.80 info. My thinking is many users are likely to continue using 2.79 for a long long time after 2.80 is released to keep 3rd party add-ons working and because 2.80 will not have Blender Internal, BGE, or compatibility with pre OpenGL 3.3 hardware. If 2.79 retains a large user base, having editable wiki docs for it makes sense.
If the pages are being flattened to HTML, this might be possible through the CSS, but web scripting is not something I have much familiarity with.
I don't think moving the old wiki will be a major issue. Last time I checked, search engines still had broken indexing for the old wiki from the prior move from wiki.blender.org to en.blender.org. Most of the older pages seem to be indexed now, but they rarely show up in the first few pages of search results unless you use rather stringent search strings. Maybe as a temp fix there could be a placeholder page at the "en.blender.org" address for a while with a 404 page or something that points to whatever the archived wiki's new address will be.
@brita : Looks like you can specify pcre regexps for wget, does this what you want? (updated:)
wget --recursive --level=1 --page-requisites --adjust-extension --convert-links --no-parent --regex-type pcre --reject-regex "Special:|action=(?!(history|edit))|printable=|oldid=|title=Talk:|limit=" -e robots=off "http://en.blender.org/index.php"
I guess you also want to remove remaining links to en.blender.org?
This removes normal, possibly multiline links to https://en.blender.org
find . -type f -exec perl -i -pe 'BEGIN{undef $/;} s/<a\ href="https://en.blender.org.?>(.?)</a>/$1/smg' {} ;
This removes
@brecht can you run Tuomo's script and add the notice to the development part saying that it's archived?
Or if not, it's not exactly clear yet how the html bake will end up on the server :)
Between https:*archive.wiki.blender.org and https:*archive.blender.org/wiki
archive.blender.org already exists. /wiki has nothing in it at the moment, but I don't know if it could cause a problem?
Apart from that, I don't have a preference. :)
Meanwhile, I made a separate task for the structure of the content and landing page -> infrastructure/blender-org#57987
@brecht @brita : If you want I can test bake first to see that everything is ok during weekend, and put that available on my own web site for you to check? You could then reproduce my process locally.
If you could add the warning about "This wiki has been archived, new wiki is available at ..." to all pages before, that would be nice. Thanks!
@TuomoKeskitalo sounds good!
Thanks for helping out ^^
Status of the wiki statification bake: This is my current version of the wget command, which has been running now for 20 hours, collected 3.4G of files, and its not yet finished.. Not sure why it is so slow, but at least it has rejected 12 million URLs so far. I hope I can run it until it finishes..
wget --recursive --level=inf --page-requisites --adjust-extension --convert-links --regex-type pcre --reject-regex "Special\:|action=(?!(history|edit))|printable=|oldid=|diff=|limit=|redlink=1|\\\"" -e robots=off --rejected-log=wget.reject.log --no-verbose --limit-rate=500k "https://en.blender.org/index.php" 2>&1 | tee wget.logUpdate 2018-11-26: Still not finished.
Update 2018-11-27: wget finished in 2d 5h. Proceeding now with string replacements. Also I found a somewhat nice way to inject warning to all pages, so no need to modify the source. More tomorrow.
Update 2018-11-28: Continuing string replacements finesse. Currently 9.6 GB of data files. Gonna take a while (tomorrow/Friday).
OK I managed to get first version of static wiki bake ready already today. I uploaded it temporarily to my web pages, please check the results here: http:*tkeskita.kapsi.fi/temp/en.blender.org/ and compare with the original at https:*en.blender.org/ and please let me know what you think. At least the tamsiteTree menus on the left panel are not working correctly, should I try to fix those?
I used the wget in previous comment and then run these bash commands to get that result:
(script updated 2018-11-30)
%%%
find . -type f -regex "..html$" -exec perl -i -pe 'BEGIN{undef $/;} s/<a\ href="https://en.blender.org.?>(.*?)</a>/$1/smg' {} ;
This removes
@TuomoKeskitalo
Is it possible to add the archived warning only on pages that are not part of the manual? Those already have a warning linking to the new Blender Manual.
I don't fully understand all the regex that is going on and what is their purpose. I would say that links from en.blender.org should be replaced by the archive domain, but never removed?
I see that the links to edit a page and see its history are not available. Is there a reason for removing them? I thought they were very useful.
When you mention that the tree menus at the left are not working, is it just the problem with the icons? Otherwise, it's working fine for me.
Hi @brita,
Yes if there is a string in manual page name it is possible to generate regex which catches and omits those. But wouldn't it be better to make all archived pages look similar?
My reasoning here is that if you ensure that no links to en.blender.org remain in the static version, you can be sure the static version is self-contained (except for css files) and no dangling links to en.blender.org remain, so then static pages can be placed or moved anywhere without breaking internal links.
I think they should be there? For example http:*tkeskita.kapsi.fi/temp/en.blender.org/index.php/Doc:2.6/Manual/index.html if you click on "view source" on top right you get to http:*tkeskita.kapsi.fi/temp/en.blender.org/index.php%3Ftitle=Doc:2.6%252FManual&action=edit.html and if you click on "history" you get http://tkeskita.kapsi.fi/temp/en.blender.org/index.php%3Ftitle=Doc:2.6%252FManual&action=history.html What page are you referring to specifically?
Oh it is working even if there is no "+" icon. Well that might be OK then, I guess.
Warning Notice
The manual pages already have a warning linking to the new manual, they shouldn't have another linking to the developer docs.
I think that the nicest thing to do is for each page, if it has the NiceTip that says "IMPORTANT! Do not update this page!", remove it entirely and add:
otherwise, add:
See paste: P848
Example:
Regex for en.blender.org
Are you trying to convert absolute links to relative ones, then?
Page Source and History
You're right, everything looks fine. I don't know where I was looking the other day. I'll poke more pages this weekend :)
Icons for the navtree
Icons should be under
/extensions/BlenderTreeAndMenu/img/.Hi @brita ,
about regexes: Yes I'm trying to modify or get rid of unconverted URLs. When wget is finished, it converts only links that point to a page it has downloaded into relative path. For the rest it does nothing. This leaves a lot of references to en.blender.org in page sources. Here attached is example of https://en.blender.org/index.php/Doc:2.6/Reference/Nodes/Node_Editor produced by wget:
Node_Editor.html
So, in order to make static pages work right, those URLs containing en.blender.org must be dealt with somehow.
I'll try to make a new conversion, including that modified treatment for NiceTip pages you requested.
I see the point of the regexes :) I would go for replacing them instead of removing, though!
Meanwhile, I notice that some links have numbers on them:
http://tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Ref/GSoC.1.html
http://tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Source/Development/Projects.1.html
This important as it actually breaks links. Do the links really need the .html at the end?
I also got this weird thing:
Last link on http://tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Ref/GSoC.1.html
has /2006 and it shouldn't (also on the navtree)
http://tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2016/Students.html
@brita :
Hmm.. Looks like wget adds a number to filename, and also ".html" to the end, when it reads URL ending in "/" (a directory, it seems to assume). Internally no links should be broken, but I guess you mean that when you replace just the host part in the old URL to new static base path you get a broken link? So you would want a rewrite/redirection rule to work on converting old URLs to static wiki pages?
OK, this has been one perl of a weekend. X-|
I've now updated the second version of static old wiki pages to http:*tkeskita.kapsi.fi/temp/en.blender.org/ including wishes by @brita for page top warnings (different for manual and other pages). I think that I managed to solve this ".1.html" issue by creating index.html from that file, so you can access pages like http:*tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode so it should be possible to use rewrite/redirection rules to map pages to archive location. Can you find something still wrong?
Here is the updated script which is fast becoming very scary looking.
(updated 2018-12-05)
Create x/index.html from ../x.html files for those directories that do not already have index.html
find . -type d > dirlist.all.txt
cat dirlist.all.txt | perl -pe 's/^./uploads.\n' | perl -pe 's/^./skins.\n' > dirlist.txt
for f in
cat dirlist.txt; dodone;
Create web list of all html pages (excluding "&action=" pages)
find . -type f -regex "..html$" > pagelist.all.txt
egrep -v "&action=" < pagelist.all.txt > pagelist.txt
cat pagelist.txt | perl -pe 's/%/%25/g' | perl -pe 's/?/%3F/g' | perl -pe 's/:/%3A/g' | perl -pe 'print $. + " "; s/^(.)$/<a href="$1">$1</a><br>/g' > pagelist.html
Create web list of all directory pages (except /uploads and /skins)
find . -type d > dirlist.all.txt
cat dirlist.all.txt | perl -pe 's/^./uploads.\n' | perl -pe 's/^./skins.\n' > dirlist.txt
rm -f dirlist.html
for f in
cat dirlist.txt; dodone
%%%
And you wonder why I never wanted to open up this can of worms ;)
I wonder though, since you seem to be so interested in converting the site, why you don't just import the wiki dump files that I put online into your own MediaWiki installation, and then code up a php file to invoke the MediaWiki parsing routines, or something similar, so that you end up with simple pages. I mean, you are putting all of this time into parsing out the CSS anyway.
Anyway, just a thought, in case you weren't aware the page dump was available (technically, the SQL can be made available after some sensitisation, if needed).
I tried the mediawiki page dump, after working through a bunch of failures and no end in sight I gave up. Since we're so close to getting it working this way there's no point anyway.
I am very very happy that someone was willing to open the can of worms, since it needed to be done. Thanks @TuomoKeskitalo !
My issues with the .1 is exactly that it doesn't allow me to simply replace the domain part, as the .1 may or may not exist. If the .html always exists, that's ok though.
Example usage "See if it exists in the Wiki Archive" in https://wiki.blender.org/wiki/A_Very_Special_Page
I'll let you know if I find more problems! (in a quick skim I only see the missing icons in the navtree)
Oh for sure. And there will always be the DB and page dump archive for some future civilisation that wants to reconstruct the wiki :D I keep such archives around in the file system as long as I can help it. I still have the old bug tracker around here somewhere blows dust off some boxes.
Anyway, poke if there is anything needed server side! Good job so far! o/
Thanks everyone, it is nice and motivating to know that your work is being appreciated! :)
I noticed that after the .1.html conversion there were still many directories without index.html. I generated index.html for those whose basename.html file could be found in the parent directory, now updated to my temporary web location.
I also generated lists, which may help searching from page names:
Some page names contain special characters, which are not converted correctly (broken link).
I'll update the script in the previous comment according to current process.
wget did not populate that directory, and when I try to access https://en.blender.org/extensions/BlenderTreeAndMenu/img/ I get 403 Forbidden..? @dmcgrath ?
I'm sorry I don't follow, can you please clarify?
I turned indexing on for that directory, for you. Try again.
In general, if something is not linked from anywhere I the site, you probably don't need to worry too much about it. Besides, that's the directory where we keep all of the secret blender documents! ;)
Thanks, I got the icons and put them to both to /extensions/TreeAndMenu/img and /extensions/BlenderTreeAndMenu/img but the navtree on left still does not show them. This is now going over my web skills. Maybe this is caused by my removal of these lines (below) in the source. If somebody knows about this, please suggest replacement strings.
%%%
%%%If you go to http:*tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Ref/GSoC.1.html and check the very last link 'Getting Started' it doesn't match the target of the same link on https:*en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode
I can see that the target page https://en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/Getting_Started was moved. Maybe that is what is causing the issue.
Icons
I don't see why you'd remove the naiad css or javascript. I'd add those 3 lines back and everything should be fine :)
Hi @brita,
Thanks for clarification. The reason why wget has changed the target is that the page https:*en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2016/Students for some reason redirects to https:*en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/Getting_Started . Wget has logically merged these two targets, and therefore http://tkeskita.kapsi.fi/temp/en.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/Getting_Started does not exist. Unfortunately I can't think of any easy way to find out these. @brecht or @dmcgrath : Is it possible to get only redirections out of mediawiki dumps? Otherwise this is impossible to fix except manually whenever a missing target is found.
Because the static wiki pages has no MediaWiki php. Wget did not convert those three URLs that contain index.php strings into anything. I need to have something as a text file I can point to in those src and href strings.
The icon problem does not seem to be related to those three removed lines I mention in #48096#571067:
The "&" in those three URLs seem to break the links, and when replaced with "&" I now got what they actually return: The first one is the only one which actually returns something:
var skin = 'naiad';
var stylepath = '/skins';
I added those two lines to end of /skins/common/wikibits.js, which should be loaded just before that script line.
Unfortunately it does not fix this missing icon issue. Anyone with javascript skills who could help? Or we can just make do without the navtree working perfectly in the static wiki archive.
Hi Tuomo. First off, great work with the wiki baking. Thank you for your help with this!
Regarding the missing icons, currently they are referred to as :
<img id="jtamsiteTree1" src="/extensions/BlenderTreeAndMenu/img/plus.gif" alt="">Which means that they are expected to be in at the root of http://tkeskita.kapsi.fi.
Currently they are at http://tkeskita.kapsi.fi/temp/en.blender.org/.
Since the plan is to move the baked wiki to https://archive.blender.org/wiki, this problem will persist. I would recommend to perform a search and replace on
/extensions/BlenderTreeAndMenu/img/and turn it into/wiki/extensions/BlenderTreeAndMenu/img/. That should solve the issue when the site is moved in the proper place.@fsiddi : Thanks, I'll do that! I briefly tested that it indeed seems to fix the icon issue.
So the biggest issue still standing is the missing of some redirected directories. @dmcgrath : Where is this mediawiki xml dump? I could maybe take a look at it. Thanks!
A few comments above in those 50 page long thread :)
https://developer.blender.org/T48096#522847
Thanks, found em! There was a file which seems to list each page and links from it to other pages, which I hope I can use. Currently it looks mildly painful though, some relative path acrobatics is needed..
Uh oh, there are some lonesome island pages in the old wiki which are never linked to --> recursive wget did not find them. I need to do new retrieval with this pagelist. Maybe no need for acrobatics.. but this will take time.
Does the wiki log whenever someone tries to visit a missing page? That would be a good way to identify broken links.
@brhumphe I don't know about mediawiki, but at least www server logs errors. Good idea to use those to make the final check, when I get there!
My current idea is to make a new retrieval with wget, but instead of trying to use recursive retrieval from root, I'll retrieve each page listed in current.dump.xml separately along with it's talk, history and edit pages. Then do similar parsing of URLs as before and see how many broken links I end up with and try to fix those. Hopefully I end up with a complete replica of the old wiki. Continuing with tests, gonna take a while.
In does indeed. I have attached a log of the 404's from December 2018 for you. Note that they also contain junk; filter as needed.
404.log.bz2
Hi,
There are PF (firewall) related limits that kick in if you make too many connections. It auto lifts after a few minutes, so no worries. I don't think we have anything configured in the Wiki Apache itself atm. If www.b.o is also not working for you, but git.blender.org is, it's a good indicator that you were blocked by the firewall. Try slowing down your crawl, otherwise, don't worry about it.
I was browsing the scraped copy last week, and bumped into a searchbox somewhere, we'd probably have to get rid of those otherwise users will use them and make tickets that it is not working.
I guess you mean the quick search on lower left corner? Good idea! I'll also remove the "Page" menu from top right and "Wiki" menu from bottom right.
Here is list of these failed pages accumulated so far. Retrieval per page is slow, so this will take maybe two more weeks until next version of static pages are ready for inspection.
failed_pages
Any History page has a bunch of broken interaction as well.
I've been wondering about history pages. After pages are static it will not be possible to do comparisons between versions, so you will only see who edited the page last and when. Is it still interesting to save history page? @brita?
If yes, I can strip away the buttons etc. from history pages, too, and leave only the list. Is it enough to save only the first history page which contains max 50 latest edits? Currently my non-recursive script retrieves only first history page.
I wouldn't worry about saving the full edit history. I'm not sure how you could preserve that without a significant increase to the total size and file count of the wiki archive. It might be helpful to see who the last 50 or 100 people that edited the page are (and maybe the first 50 edits), but if someone needed more info than that they could download the wiki data dump.
Agree, I wouldn't worry too much about fixing every broken link. It's nice if it doesn't take too much time, but for an archived website it's ok if only the basics are functional.
Ok, new version of archived wiki is available temporarily for review at http://tkeskita.kapsi.fi/temp/en.blender.org/
5317353209 out of 53221, and all page directories listed in the XML dump have index.html, so I think it is now pretty much complete.statify.sh
I fixed a ton of my errors along the way, so I'm pretty sure somewhere there is still something wrong, but I'm now pretty happy with the result. Can anyone still find something wrong?
Update 2019-01-01: Retrieved deleted pages again, fixed statify.sh and whole packet accordingly.
Download link for the whole packet: http://tkeskita.kapsi.fi/temp/en.blender.org.tar.bz2
Update 2019-01-03: Updated few missing pages, page count from 53173 to 53209.
Update 2019-01-04: Updated pagelist accordingly.
I would keep all the deleted pages and their redirects. This would avoid broken links.
I don't think that the asccii character issue is is a good compromise as this will result in broken links? Or maybe I misunderstood something.
Imo, the broken functionality in the history and wiki menu is ok. It's an archive. I would definitely keep the history pages with the list of edits, which includes date, author and description. I agree that the last 50 edits should be enough.
If I type either "Release_Notes" or "Release Notes" in the URL both will work? This sounds fine.
Do you know what is missing so that 53173 is not exactly 53209?
Hi!
Deleted pages are there, but without redirects. This means that, for deleted pages, you get the same view as you would get for it now in the mediawiki, but the page name remains original. If you then go to edit page, you see the redirection if that is needed. OK?
Yes the character issue does result in links from outside to archived wiki being broken, but I don't how this could be made better with static pages. Any ideas? At least the pages are there, although their name is not readable..
OK so I think that's how it is now. Please check though.
No. It's like trying to find needle in haystack. I've been able to decrease count to 53209/53218. It is related to some special character(s) most likely, so that two page names evaluate to same path.
There seems to be some weirdness going on if wiki user's created subpages without a base page.
Compare these 2:
Despite the unusual look of the second page, I think having a "fallback base page" in this circumstance is nice as it makes it easier to find subpages. I suspect, in some cases, making subpages harder to find may have been intentional on part of the page authors, but I'm not sure it makes sense to leave those pages "hidden" anymore.
On a different note, would it be worth archiving some of the "wiki special pages" from the old wiki? Two of the special pages I've often used for cross-referencing appear to have been skipped:
The "what links here" pages:
https://en.blender.org/index.php/Special:WhatLinksHere/Dev:Doc/Blender_Source/Files_Structure
And recent user contributions:
https://en.blender.org/index.php?title=Special:Contributions&limit=100&target=NBurn
These pages can be helpful when trying to find more info related to an article, but adding them back could significantly increase the size of the wiki archive.
Lastly, I'm not sure if the "warning" part is needed in the disclaimer at the top. Maybe:
And have a new (non-google) link attached to "archived version" instead of just the one to the newer wiki at the end. I was thinking possibly a brief FAQ type page, maybe something like:
Thoughts?
Yes, the only special pages currently included are the edit and history pages. Technically, all those specials (non-existing parent page, what links here, recent user contributions for User:X pages) can be added, if someone else also seconds this motion? "What links here" and "recent user contributions" could be retrieved to e.g. links.html and contributions.html located under page folders. I don't think they would add too much to archive size, it would just take me time to do it.
But first I need to get some sort of approval for the current retrieve+processing result, so gonna wait for a while.
Hi, I'm now contemplating to do another full retrieve, so this would be a perfect time to make decisions about suggestions from @nBurn in #48096#594983. Anyone else also want those changes?
I've been digging into this special characters issue, and it seems that wget option --restrict-file-names=nocontrol might preserve special characters correctly, so there would be no need for transcribing page names to hexadecimals (%XX). However, this means that I would need to do third full retrieve from scratch. Last time it took 10 days(!), which is slooow. As a workaround, I'm thinking to set up a local Apache + Mediawiki installation for myself where I try to restore the old mediawiki dump , and retrieve from there. @dmcgrath Is MediaWiki 1.16.2 correct version to use? Maybe add the Mediawiki version to README.txt in the mediawiki dump?
It looks like old Mediawiki doesn't want to work nicely with php7. Also there's no guarantee that the result will look anything like the current one, so I guess its gonna be a new 10 d crawl..
Update 2019-01-15: New crawl started including what-links-here.
Third retrieve is proceeding (slowly), and in ~4 days it should be finished. At that time (before running html processing for all pages) I need feedback about suggestion in #48096#594983 by @nBurn to change warning text (and add link to an explanatory page). @brita, @fsiddi, @Blendify, anyone: do you agree? What URL to add for explanatory page? Some page in new wiki? Or better to leave warning as it is now?
I decided already to include other suggestions by @nBurn.
I would recommend having a clear message stating that the wiki contains legacy information and to visit wiki.blender.org for the active wiki documentation. Something along the lines of what @nBurn suggested.
This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.Thanks for your work!
OK, I'm glad to inform you that the static old wiki baking is finished. The current version is uploaded temporarily to http:*tkeskita.kapsi.fi/temp/en.blender.org and download package is available in http:*tkeskita.kapsi.fi/temp
statify.sh
Please let me know if you find something wrong. Thanks!
It looks great, I found no problems. Thanks a lot for doing this.
I've copied the whole thing to https://archive.blender.org/wiki/.
Now it's just a matter of setting up a redirect from en.blender.org to archive.blender.org/wiki and taking the old wiki offline (I guess we keep a backup).
@dmcgrath, can you do that?
It should be done. I redirect everything except
/robots.txtto archive.b.o/wiki.I will start archival procedures of the MySQL db and on disk files and place them in the wiki's /root folder, clean up old on disk cache files, etc.
Thanks @TuomoKeskitalo! And thanks @brecht.
From a quick look the archived wiki seems to be running well in all its legacy glory.
Looking forward to the last steps that Dan will perform.
@fsiddi It should already be redirecting en.blender.org to archive.blender.org/wiki/ since my last post.
Great! I guess that the 2 remaining points (Utilities and Delete the old read-only PHP wiki) can be wrapped up as well?
After that, I propose to close this task and move any other todo to separate topics, tagged as Documentation.
The old wiki should be inaccessible already, but I will have to purge the files from disk before it's technically "deleted". The directory is archived though, already. I won't erase the SQL db until I can test the dump was fine, but initial glance suggests it's all good.
How does the archive look with the redirects etc?
Redirects are working well.
Other todo's are here:
Good to hear.
Well the cleanup on the server side should be final now. I dumped and compared/verified both the only disk files, and the database dump.
I have left a copy of the tarball in
/root/en.blender.org.tar.bz2. Feel free to grab a copy (~5.5G). This contains the vhost docroot, the old txt only dumps, and the database dump.I forgot to mention that the old vhost docroot files have be entirely deleted, as well as the original database. The old docroot is a mere empty skeleton, needed to satisfy the Apache docroot path, as well as provide a means for Certbot (Lets Encrypt) to acquire its certificates. Once the snapshots rotate enough, the space from the old files will be reclaimed.
Changed status from 'Open' to: 'Resolved'
Let's consider this resolved then.
I wouldn't know what to do with that file, I just imagined you had someplace to archive these kinds of things.
Generally I just keep old stuff around where it originally was left, or I move (tarball) it to the root dir. It's tough since our rack never had a central storage location, unless you consider download.blender.org. I have started throwing secondary copies of stuff into CephFS. Who knows, if we keep it around, it might be the new "attic" (what I put such things).
Glad that you like the result! Cheers for ye olde wiki! :-)
One small thing I noticed: 2.79 release notes page has an outdated Note box on top you may want to manually remove.
@Tuomo, note box removed.