Redirects for Coding standard pages to GitLab pages

Can we go ahead and delete the www.drupal.org pages right away, as redirects are added?

I am not sure we should delete them and lose all the history. Can we archive them somewhere?

I don't if there is a top-level redirect, but the single page example in the issue summary https://www.drupal.org/docs/develop/coding-standards/namespaces → still displays the old page.

We recently had an update to the PHP coding standards page → to which @quietone had to revert and created 📌 Add nameing for TWIG variables Active instead. So the sooner that people cannot make those edits the better it will be.

I am not sure we should delete them and lose all the history. Can we archive them somewhere?
report

Related question that comes to mind after recently revisiting an incident (couple years ago) where a site moderator deleted content and re-posted it.

How has the CC-BY-SA 2.0 been honored in the new coding standards repo for these? Was every revision given a commit or is D.O. dependent upon retaining these links to retain a record of who changed what and when to attribute it? (Though a deeper question; does the edit history itself even comply with the license if multiple contributors were involved in editing the source changes in the issue queue.)

We’ll have to decide on redirect & delete OR keeping the pages for the history, with a notice at the top directing to the new version.

Redirects without deleting make the old pages mostly inaccessible, so they might as well be deleted. If we go this route, we need a list of URLs of pages to delete and their replacement URL.

If we do keep the old pages for their history, a notice could be added above the text like we have for Drupal 7 documentation, https://www.drupal.org/docs/7/install/before-installation → . And/or a specific message with the exact replacement page can be edited into each documentation page. If we go this route, we need the text for the message.

There isn’t a great way to control edits to documentation pages, community editing is generally a feature.

This is being discussed in Slack, #coding_standards, and is not yet a decision. These are just my thoughts.

The pages where the history does not refer to an issue or is otherwise minimal or not helpful to researching history of a change can be redirected and deleted. This is the majority.

The other pages which have revision history of importance should be redirected but not deleted. This includes the 'main' PHP page which has lots of history. All together I think there are 14 such pages.

For these, the message at the top could be

This page is archived. It is kept in order to research changes made to the Drupal Coding Standards.

No changes should be made to this page.

Read the current Drupal Coding standards.

Also, the title could be changed to have [archive] at the start. That might help to deter eager editors as well.

To be found by those interested in Coding Standards I was thinking of a 'Reference' section on the project page that would explain the archived pages and provide the links.

The 14 pages are

1. https://www.drupal.org/docs/develop/standards/php/php-coding-standards →
2. https://www.drupal.org/docs/develop/standards/php/api-documentation-and-... →
3. https://www.drupal.org/docs/develop/coding-standards/namespaces →
4. https://www.drupal.org/docs/develop/coding-standards/php-exceptions →
5. https://www.drupal.org/docs/develop/standards/php/psr-4-namespaces-and-a... →
6. https://www.drupal.org/docs/develop/standards/javascript-coding-standard... →
7. https://www.drupal.org/docs/develop/standards/javascript-coding-standard... →
8. https://www.drupal.org/docs/develop/standards/javascript/jquery-coding-s... →
9. https://www.drupal.org/docs/develop/standards/sql/sql-coding-conventions →
10. https://www.drupal.org/docs/develop/coding-standards/list-of-sql-reserve... →
11. https://www.drupal.org/docs/develop/coding-standards/avoid-select-from →
12. https://www.drupal.org/docs/develop/coding-standards/configuration-file-... →
13. https://www.drupal.org/docs/develop/coding-standards/composer-package-na... →
14. https://www.drupal.org/docs/develop/coding-standards/twig-coding-standards →

While I would probably be OK living without the history, I've definitely gone through it to see when slightly odd looking coding standards might have been introduced before - e.g. did it come from an issue or was it a typo etc.

Since we're only interested in the history and not the pages, I wonder if this might actually be an option:

Redirects without deleting make the old pages mostly inaccessible, so they might as well be deleted.

e.g. as long as we have a list of node IDs somewhere, we can get to the revision history pages if we really need to, and otherwise to all intents and purposes those pages don't exist.

Another option would be to migrate the history to the pages, just commit from start, maybe even add real commit date and work from there. Although what catch suggests is a lot less work, so wouldn't really mind that. It might mean some issues when we migrate to a new site though, so my preference would be to do the work of creating the history in git.

I think, asssuming we use markdown, this could just mean move through history, copy html, convert to markdown, add proper commit message. Next.

> I think, asssuming we use markdown, this could just mean move through history, copy html, convert to markdown, add proper commit message. Next.

This could be an option, but that seems like a lot of work - it would mean we can delete all these pages easily from d.o, so that has my preference as well. I hope this can be scripted, because there are a lot of revisions on some of those pages.

I was hoping for API revisions, but seems those are not available. Would a revision history from the database be possible perhaps @drumm think we only need: title, body, revision date, user (maybenot)? Converting html to MD is easy, and if we have a csv with the revision history it should be quite easy.

Loading and copy pasting each revision is a little more effort :p

If I am reading this correctly then the consensus is to go with "Redirects without deleting make the old pages mostly inaccessible, so they might as well be deleted."

Being 'mostly' inaccessible is helpful for the Coding Standards Committee. It allows the history to be available to the Committee and those interested in coding standards. If they happen to get edited, the committee will have to follow up on that.

I updated the proposed resolution with all the URLs in the Coding standard guide as asked for in #6. I have also split them to two groups because not all the pages have history that needs to be kept.

I am not sure what the replacement URL should be for the pages that are to kept for their history.

@borisson_ suggested that a replacement URL isn't necessary, that we just use the Node ID. And catch said the same in #8.
So let's do that.