- Issue created by @Bhanu951
- @bhanu951 opened merge request.
- Status changed to Needs review
10 months ago 1:14pm 7 November 2023 - Status changed to Needs work
10 months ago 1:46pm 7 November 2023 - First commit to issue fork.
- 🇮🇳India Bhanu951
@saurabh_jain I don't get why you reverted those changes?
This issue is about making exact those changes.
Replacing all http URLs with https in core.
- 🇮🇳India Bhanu951
Should this be handled as a single issue or should it be split into multiple smaller issues ?
IF smaller issues on what criteria they should be split ?
Based on Domain names ? or module components or any other ?
I would suggest let's make it a strictly first time contributor issues to get new contributors familiar with contribution.
- 🇳🇿New Zealand quietone New Zealand
Yes, let's re-scope this into small, easier to review issues. Ideally, the scope is by the type of fix which makes it much easier for reviewers. I haven't looked closed enough but it may be possible to have an issue for user facing strings, one for comments, one for tests, and one for production code. I did see there are a lot of changes to .svg files, which could be a separate issue. So, this issue could be the Meta with children. And when, the children are fixed this could be used to fix any stragglers that have crept in to the code base.
Some other thoughts
1. Any ideas on how to prevent 'http:' in the future
2. Are there tests that are specifically testing http that should not be changed?
3. the migrate test fixtures drupal6.php and durpal7.php are not to be changed. - 🇺🇸United States mikelutz Michigan, USA
For lack of my 7am brain being able to come up with a clever way to do this in bash, running
<?php $f = fopen("5278.diff", "r"); $regxp = "/https:\/\/([a-z0-9A-Z\.-]+)[^a-z0-9A-Z\.-]/i"; $matches = []; $results = []; while (!feof($f)) { $line = fgets($f); if (preg_match($regxp, $line, $matches)) { $results[$matches[1]] = isset($results[$matches[1]]) ? $results[$matches[1]] + 1 : 1; } } array_multisort($results, SORT_DESC); foreach ($results as $name => $count) { echo $name . ": " . $count . "\n"; }
on the original MR gives
example.com: 1412 www.w3.org: 747 www.example.com: 136 jsonapi.org: 77 jqueryui.com: 58 jquery.org: 48 www.drupal.org: 40 api.jqueryui.com: 37 drupal.org: 22 www.test.com: 20 wikipedia.org: 18 google.com: 14 docs.jquery.com: 9 www.doctrine-project.org: 8 fonts.fontprovider.com: 8 php.net: 7 www.sqlite.org: 7 en.wikipedia.org: 7 api.drupal.org: 7 www.collegehumor.com: 7 symfony.com: 6
along with ~80 additional domains with < 5 usages
The numbers are a bit off from the actual work between codebase changes and the vendor changes to be undone. Also the xmnls in the svg files should not be changed, https://www.w3.org/2000/svg is an identifier, not a url, and it should not be https. Still probably a good baseline to start with. Having discussed scoping child issues of metas like this several times with @xjm in the recent past, I'm fairly confident we should be doing this by domain for the top domains and then catch the one-offs in a separate issues or issues as it makes sense. These are probably not novice issues (at least not all) as there are many places where this should not be changed at all. Let's start with a child issues for
example.com: 1412
www.w3.org: 747
www.example.com: 136
jsonapi.org: 77
jqueryui.com: 58
jquery.org: 48
www.drupal.org: 40
api.jqueryui.com: 37
drupal.org: 22
www.test.com: 20
<\code>and go from there. We can also probably standardize on replacing http://example.com with https://www.example.com and http://drupal.org with https://www.drupal.org while we are at it.
- Status changed to Active
about 2 months ago 5:18pm 21 July 2024 - 🇳🇿New Zealand quietone New Zealand
@mikelutz, thanks for the script and the numbers. Doing this by URL makes sense to me now.