Hello @ll, after reporting tdf#64397 in the past, I found out, that this option got even worse ... :( Steps to reproduce: 1. Start LO 2. Go to "Tools - Options - Internet - MediaWiki" 3. Click on "Add..." 4. Enter an URL, your username there and your password 5. Additionally, but it does not matter, mark "Save password" In the past, I was able to enter https://de.wikipedia.org as URL, with my username and password there, and clicking on OK added this account to LO. Nowadays, I only get an error message: <quote> A connection to the MediaWiki system at 'https://de.wikipedia.org/wiki/Wikipedia:Hauptseite' could not be created. </quote> ... :( If I use www.wikipedia.org (or say http://mein.homelinux.com (where I have no account)), I get the error message <quote> A connection to the MediaWiki system at 'https://www.wikipedia.org' could not be created. </quote> or <quote> A connection to the MediaWiki system at 'http://mein.homelinux.com' could not be created. </quote> Tested with LO Version: 5.0.4.2 Build-ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Gebietsschema: de-DE (de_DE.UTF-8) Version: 5.0.5.1 Build-ID: 7609023f63524a6c8326f6c82e7e23f55a5b7bb5 Gebietsschema: de-DE (de_DE.UTF-8) Version: 5.1.0.3 Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 4; OS Version: Linux 4.3; UI Render: default; Locale: de-DE (de_DE.UTF-8) (all three parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel/Linux) on Debian Testing AMD64 w/ de_DE lang- as well as helppack. If I do this with LO Version: 5.0.0.5 Build-ID: 437e4abdf9e72fd0a6e6f8697a0e659bc77f9b10 Gebietsschema: de-DE (de_DE.UTF-8) (also parallel installed) – and I am pretty sure, that this has also worked with earlier LO versions of LO before 5.0.4.2 – it works ... Sorry for the inconvenience Thomas.
Hmm, no fun here either. In 5.1.0.3 I get a different error (wrong name/pwd whatever). And funny output on the console: 11-feb-2016 14:00:19 org.apache.commons.httpclient.HttpMethodBase getResponseBody WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. 11-feb-2016 14:00:23 org.apache.commons.httpclient.HttpMethodBase getResponseBody WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. com.sun.star.uno.RuntimeException: [jni_uno bridge error] Java calling UNO method hasByName: [map_to_uno():string] null-ref given! java stack trace: at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method) at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185) at com.sun.proxy.$Proxy13.hasByName(Unknown Source) at com.sun.star.wiki.Helper.AllowUnknownCert(Helper.java:944) at com.sun.star.wiki.Helper.ExecuteMethod(Helper.java:662) at com.sun.star.wiki.Helper.Login(Helper.java:782) at com.sun.star.wiki.WikiEditSettingDialog.DoLogin(WikiEditSettingDialog.java:257) at com.sun.star.wiki.WikiEditSettingDialog.access$000(WikiEditSettingDialog.java:35) at com.sun.star.wiki.WikiEditSettingDialog$1.run(WikiEditSettingDialog.java:377) at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method) at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185) at com.sun.proxy.$Proxy13.hasByName(Unknown Source) at com.sun.star.wiki.Helper.AllowUnknownCert(Helper.java:944) at com.sun.star.wiki.Helper.ExecuteMethod(Helper.java:662) at com.sun.star.wiki.Helper.Login(Helper.java:782) at com.sun.star.wiki.WikiEditSettingDialog.DoLogin(WikiEditSettingDialog.java:257) at com.sun.star.wiki.WikiEditSettingDialog.access$000(WikiEditSettingDialog.java:35) at com.sun.star.wiki.WikiEditSettingDialog$1.run(WikiEditSettingDialog.java:377)
hmm.. trying a different URL does work. Sorry
Hello Cor, (In reply to Cor Nouws from comment #2) > hmm.. trying a different URL does work. Sorry thanks for trying :) just out of interest: Which URL does work for you? Have a nice afternoon Thomas.
https://wiki.documentfoundation.org/Main_Page does not https://wiki.documentfoundation.org does ...
(In reply to Cor Nouws from comment #4) > https://wiki.documentfoundation.org/Main_Page does not > https://wiki.documentfoundation.org does ... interesting. The last one still leads to my found bug #64397 ... :( Thanks for your answer Thomas.
I was able to add https://fi.wikipedia.org/ just fine. It changed it to: https://fi.wikipedia.org/w/ Win 7 Pro 64-bit, Version: 5.1.0.3 (x64) Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: fi-FI (fi_FI)
Hello Beluga, *, (In reply to Beluga from comment #6) > I was able to add https://fi.wikipedia.org/ just fine. It changed it to: > https://fi.wikipedia.org/w/ > > Win 7 Pro 64-bit, Version: 5.1.0.3 (x64) > Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 > CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; > Locale: fi-FI (fi_FI) thanks for testing :) Interestingly enough, I am also able to add the Finnish one, but not the de-de (https://de.wikipedia.org) one ... :( Would you be so kind to test it with it, too? Thanks in Advance Thomas.
Reproduced with https://de.wikipedia.org/
Hello Beluga, *, (In reply to Beluga from comment #8) > Reproduced with https://de.wikipedia.org/ thanks for confirming :) Have a nice evening Thomas.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Hello *, (In reply to QA Administrators from comment #10) <snip> > Test to see if the bug is still present on a currently supported version of > LibreOffice > (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ > > If the bug is present, please leave a comment that includes the version of > LibreOffice and > your operating system, and any changes you see in the bug behavior It is still reproducible with OS: Debian Testing AMD64 LO: Version: 5.1.6.2 Build-ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909 CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group LO: Version: 5.2.6.2 Build-ID: a3100ed2409ebf1c212f5048fbe377c281438fdc CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group LO: Version: 5.3.1.1 Build-ID: 72fee18f394a980128dc111963f2eefb05998eeb CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group LO: Version: 5.3.2.0.0+ Build-ID: ae225329435cb49e61e3c9fc76129aa4e334598a CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-02-27_23:15:07 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group and LO: Version: 5.4.0.0.alpha0+ Build-ID: 08750abc64a7ad82cac96adeb7a0bcdce7ac704d CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-02-28_00:23:27 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group , sorry ... :( HTH Thomas.
Let's give it a try with https://gerrit.libreoffice.org/#/c/38631/
I should have read comments in detail. The problem is some websites use w/index.php (wikipedia) other use /index.php (wiki.documentfoundation.org). Now I just wonder if there's some standard (and tdf wiki should be fixed) or if we should find a way so LO retrieves the right link.
I gave a new try with a different approach to focus on the retrieving of the right main url.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e34b02834b24be4062ffd535aa1b929481ff427e tdf#97743: mediawiki account It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just for information, master sources correspond now to 6.0.0 (and not 5.5.0 for marketing reason). Anyway, if someone could give a try to daily master (see http://dev-builds.libreoffice.org/daily/master/) when patch there'll be some release with patch included.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f283f3a31cff295dbc06af95430f0b26bf2bc9a3&h=libreoffice-5-4 tdf#97743: mediawiki account It will be available in 5.4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm wondering if it's ok that instead of initial url provided by the user, it's the main url detected which is saved in settings. I mean if I put "https://fr.wikipedia.org", it saves "https://fr.wikipedia.org/w/" For "https://wiki.documentfoundation.org/", no pb because main url doesn't contain anything more. What's expected here?
Does anybody have access to an OLD wiki? (something like 1.18; maybe up to 1.21) I guess the wiki publisher still works with old wikis as nowadays (as explained in the gerrit) is protecting the main page (except for admins, because of spam and vandalism) which will causing this bug.
Hello Julien, *, sorry for the delay, but did not find the time to answer earlier ... :( (In reply to Julien Nabet from comment #18) > I'm wondering if it's ok that instead of initial url provided by the user, > it's the main url detected which is saved in settings. > I mean if I put "https://fr.wikipedia.org", it saves > "https://fr.wikipedia.org/w/" If I use my WP's user name and password and check "Save password", it does not work (leads to the error message which I mentioned in comment 1). If I empty both fields (but with the already entered URL and checked "Save password"), it works ... > For "https://wiki.documentfoundation.org/", no pb because main url doesn't > contain anything more. O.K. > What's expected here? No idea, sorry ... :( Thank you very much for all your work and have a nice Sunday :) Thomas.
(In reply to Julien Nabet from comment #18) > I'm wondering if it's ok that instead of initial url provided by the user, > it's the main url detected which is saved in settings. > I mean if I put "https://fr.wikipedia.org", it saves > "https://fr.wikipedia.org/w/" > > For "https://wiki.documentfoundation.org/", no pb because main url doesn't > contain anything more. > > What's expected here? The path of the index.php is expected here. depending on the configuration of mediawiki this can be lying at sme other places (some use /w/ some wikis do use /wiki/, etc.) I think that's hard to explain for the user which url to enter there. i guess wee need some detection. :-(
Dennis: sorry for the delay, I was away from my laptop the 2 last weeks. I don't understand about detection since it's already done by the fix. To sum up, according to last comments (from gerrit or bugzilla), I should: - remove opensearch_desc.php and load.php and put api.php instead for detection - let LO save the detected path, => as I indicated in comment 18 in first example, if the user typed "https://fr.wikipedia.org", the saved path will be "https://fr.wikipedia.org/w/" it's already what the fix does. Is it ok for you or did I miss and/or misunderstand something?
Hello Julien, *, thank you for your work on this bug :) However, it is still not fixed in OS: Debian Testing AMD64 LO: LO: Version: 5.3.6.0.0+ Build-ID: c967cebeab0d5b343bd33d3a6f758aeaa40258f8 CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-07-21_05:36:28 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group but in LO: Version: 5.4.1.0.0+ Build-ID: 6622ea7365fbf1b425e5f90667dd7e6466fd0293 CPU-Threads: 4; Betriebssystem:Linux 4.5; UI-Render: Standard; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2017-07-21_06:37:51 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group LO: Version: 5.4.0.3 Build-ID: 92c2794a7c181ba4c1c5053618179937228ed1fb CPU-Threads: 4; Betriebssystem:Linux 4.5; UI-Render: Standard; VCL: gtk2; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group and LO: Version: 6.0.0.0.alpha0+ Build-ID: e0bafa78e3ad0df397d78cd65ad19bd5b07dc5f2 CPU-Threads: 4; Betriebssystem:Linux 4.5; UI-Render: Standard; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-20_22:42:49 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group it is working now :) Thanks again for your work and have a nice Sunday Thomas.
(In reply to thackert from comment #23) > Hello Julien, *, > thank you for your work on this bug :) However, it is still not fixed in > > OS: Debian Testing AMD64 > LO: LO: Version: 5.3.6.0.0+ > ... Hi thackert, 5.3 backport is still on gerrit. Following Dennis' comment, it seems the fix needs some changes. So the goal is first to change it on master, then on 5.4 and finally on 5.3. I described in my previous comment the actions to do to to be sure it's ok for Dennis. If it is, I'll submit a new patch for master to begin. Since you tested this new version, did it work well on different situations you may have encountered? What do you think about the fact that url saved on LO may be different from the one typed by the user? (see previous comments) Is it confusing?
Hello Julien, *, (In reply to Julien Nabet from comment #24) > (In reply to thackert from comment #23) > > thank you for your work on this bug :) However, it is still not fixed in > > > > OS: Debian Testing AMD64 > > LO: LO: Version: 5.3.6.0.0+ > > 5.3 backport is still on gerrit. Following Dennis' comment, it seems the fix > needs some changes. So the goal is first to change it on master, then on 5.4 > and finally on 5.3. I described in my previous comment the actions to do to > to be sure it's ok for Dennis. If it is, I'll submit a new patch for master > to begin. O.K. > Since you tested this new version, did it work well on different situations > you may have encountered? Which different situations? I tested it with my Wikipedia account for de.wikipedia.org as well as for wikipedia.org and also with my TDF wiki account. I could add all of them without any problem. > What do you think about the fact that url saved on LO may be different from > the one typed by the user? (see previous comments) Is it confusing? Not for me. I am glad that I am able now to add wikipedia as well as wiki.documentfoundation with https to LO ... ;) Have a nice day Thomas.
(In reply to Julien Nabet from comment #22) > Dennis: sorry for the delay, I was away from my laptop the 2 last weeks. > I don't understand about detection since it's already done by the fix. > To sum up, according to last comments (from gerrit or bugzilla), I should: > - remove opensearch_desc.php and load.php and put api.php instead for > detection > - let LO save the detected path, > => as I indicated in comment 18 in first example, if the user typed > "https://fr.wikipedia.org", the saved path will be > "https://fr.wikipedia.org/w/" > it's already what the fix does. > > Is it ok for you or did I miss and/or misunderstand something? Oh sorry; no. I were a bit confused (neither I hadn't any time to check if the fix works now) and also tried to explain the situation / the background. The api.php is the best. If that is deactivated in the wiki; we also have no possibility to push our changes. ;-) Feel free to push the change to 5.3 as Thomas already confirmed it working.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c51e789b3a5b77b8bca03c3404699655b19ac80d&h=libreoffice-5-3 tdf#97743: mediawiki account It will be available in 5.3.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Dennis Roczek from comment #26) >... > Oh sorry; no. I were a bit confused (neither I hadn't any time to check if > the fix works now) and also tried to explain the situation / the background. > The api.php is the best. If that is deactivated in the wiki; we also have no > possibility to push our changes. ;-) > > Feel free to push the change to 5.3 as Thomas already confirmed it working. Thank you for your feedback, I submitted the patch as it was.