- Mentioned In
- T244135: Publish current version of QRpedia code in a public code repository
T214394: QR codes in Stockholm for Wikimania
T214268: qrwp.org URL results in double slash and broken link for non-English languages
T210050: Page titles are being double-encoded
- Mentioned Here
- T214268: qrwp.org URL results in double slash and broken link for non-English languages
T210050: Page titles are being double-encoded
Removing the ops/traffic/domains tags, as the Foundation doesn't operate anything about these domains (we don't own or operate the DNS, the IPs, or the servers). Whois says they belong to:
Registrant Organization: Cultural Outreach Limited Registrant State/Province: London Registrant Country: GB
For qrpedia.org, the DNS and hosting appears to be with Amazon Web Services, and for qrwp.org, it's LiveDNS.co.uk for the DNS and Rackspace for the hosting.
asking is it possible to for the qrpedia to be replaced or redirtected to https://meta.wikimedia.org/wiki/Free_Knowledge_Portal which is on the toolserver and uses the stable qnumbers from wikidata
Hi; not sure how to flag this but QRPedia issues are probably best assigned to me for now.
I've been made aware of the issue & its something I can get fixed. ETA will probably be later tonight or tomorrow.
Have just heard from Toodyay all the codes created before this went are no longer working, new codes being created now are fine, unfortunately our partner has invested in replacements for all of the original plates and now nothing works
https://commons.wikimedia.org/wiki/File:Toodyaypedia_plates_stg_1_gnangarra_fs-1.jpg for an original code created in 2014, and we have another set created in 2016 that also dont work... Its not a good look
In addition to the codes in Toodyay we also have codes in Fremantle, as well some in Sydney and on all of WMAU business cards so a fix would be preferred to the costly exercise of replacing everything
@Aklapper Thanks, that's useful!
Apologies for the delay in replying; I had believed this to be fixed. Unfortunately @Gnangarra reply suggests otherwise! I'll look into it ASAP.
If possible could you share as many qrwp.org links as possible? The codebase isn't mine and it's a bit old and needs some TLC in places. So as much info as you have is helpful.
To put the scope of the problem in context - the redirect code just didn't work well at all & so I'm using an Nginx config to manage the redirect, which I suspect has unexpected behaviours. Sharing as much data as possible will help me fix it.
I have just uploaded the original QRcodes to Commons, here is a the category of codes created for toodyay in 2014 https://commons.wikimedia.org/wiki/Category:QRpedia_codes_for_Toodyay
@ErrantX it looks like qrwp.org is still not working (both HTTPS and not, and with and without www.). But en.qrwp.org is working for both HTTPS and not (yay! that means lots, but perhaps not all, of the codes are working I think?).
Is the source code available publicly anywhere? Would it help to have another pair of eyes on it? Or are these problems all server-config related?
Thanks for working on it!
It looks like there's some issues with double-encoding in some codes. For example, the centre plaque in
(i.e. the % was URL-encoded a second time).
Did a prior version of the QRpedia software handle this double-encoding, or was this code always incorrect?
we are still having issues with apostrophes within a page title not working. https://meta.wikimedia.org/wiki/Free_Knowledge_Portal addresses the issue and provides its linking via Wikidata, WMAu has some resources in its new sAPG to help transition qrpedia to Wikidata as the hub where special characters in URL are no longer needed.
The issues still persist:
a) Double slashes in de.Wikipedia: https://de.qrwp.org/Berlin
The solution should be known at WMUK, because the bug has been fixed for other language versions.
b) Incorrect URL resolution for articles with non-letter character:
The issue already existed once in 2014, but was quickly fixed by a simple method at qrwp.org: With the incoming URL, do a regex_replace or string_replace, find '%25' replace with '%'.
I would like to know why the fix was undone.
This task is called "qrpedia.org and qrwp.org are down/offline".
This task is still open because http://qrpedia.org cannot be reached.
Anything else, like double slashes, is offtopic here because it is not about a complete websites being offline.
Please report separate tasks for separate problems. See https://www.mediawiki.org/wiki/How_to_report_a_bug .
@Gnangarra: No, this is not how it works. Please do not intentionally add unrelated comments to task if you would like to continue being active in Wikimedia Phabricator. One task per one issue, as explained before. Resources are unlimited. Please read "Why has nobody fixed this issue yet?" on https://www.mediawiki.org/wiki/Bug_management/Development_prioritization . Thanks.
Resources are unlimited
Mine, and I suspect @Gnangarra's and other volunteers', are not.
Please read "Why has nobody fixed this issue yet?"
I've read that. I cannot see the bit about high profile and public-facing - not to mention external-partnership - projects which remain inoperable after many months.
Basically yeah, the problems have been around for over two years, if stopping me from being active on phabricator is going to fix the problems with the QR codes I have no problem with that option
@Aklapper there may be a misundertsanding here, my understanding is QRpedia isnt working, it hasnt been working for over two years, I dont have the knowledge to decide on the nuances of whether its related to the same or different lines of code all I know is its not functioning. the message we get is bad url/url doesnt exist. and we've been getting that for a couple of years.
status as of today:
- qrpedia.org can be reached and i see a form to create QR codes
- qrwp.org can be reached but just redirects me to the en.wikipedia main page
So technically both are "up" now and this ticket can be closed. Assuming that this is the desired state, with qrpedia.org being the tool to create codes and qrwp.org being the one that does the redirects to articles when codes are being used.
qrwp.org without any subdomain or path is meant to redirect to enwp main page, so that's good. It seems that URLs like https://fr.qrwp.org/Trait%C3%A9_de_Paris_(1815) are redirecting correctly (although with the extra-slash problem described in T214268).
However, I'm not sure if everything is fine, because this still says it's down: https://downforeveryoneorjustme.com/qrwp.org and from my machine here I get intermittent results, e.g.:
$ curl -I http://qrwp.org curl: (6) Could not resolve host: qrwp.org
@ErrantX For some reason i was able to open qrwp.org and got to the en.wikipedia front page earlier but also i can confirm now it's like there is no DNS entry for it. It says AWS name servers are responsible. could you take a look at DNS settings there? Currently there seems to be no A or CNAME record for qrwp.org .
edit: while there are DNS records for fr.qwp.org and en.qwp.org.. so this is just about the blank domain name
An A record has now been added to AWS for the name qrwp.org Whois shows what we expect in terms of DNS, resellers etc.
The code is written to redirect any requests to qrwp.org without a two-letter language-code prefix to qpredia.org. As qrwp.org is not the main URL for the site, I'm guessing that was why it wasn't fully set up in DNS originally.
Reviewing and triaging these tasks.
Is the issue that QR codes are being incorrectly generated with URLs pointing to http://qrwp.org rather than fr.qrwp.org etc.?
If so there should be a separate task.
Adding some kind of redirect for qrwp.org would be OK, but assuming these codes are not arising from the QR codes themselves, I think this task should be lower priority.