Bugs item #3528259, was opened at 2012-05-19 09:38
Message generated for change (Settings changed) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3528259&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: xqt (xqt)
>Summary: PostData() datas are not gzip compressed
Initial Comment:
Using the 'pagegenerators', data transfer is not compressed.
That data will be several megabytes.
That transfer is very time consuming.
Therefore, I think a good idea to remove that line.
Thank you consider.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 07:20
Message:
Maybe the header is wrong. I found 'Accept-encoding' as header parameter
but at https://www.mediawiki.org/wiki/API:Client_Code header is described
as 'Accept-Encoding' (capital Encoding)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 06:41
Message:
I was confirmed by Wireshark.
This is a packet analysis software.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 06:31
Message:
I don't know whether they are compressed or not. How did you see it?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 05:15
Message:
I understand. In the request header are described.
However, the response data are not compressed.
May be a bug of MediaWiki.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 02:04
Message:
This has nothing to do with preloading generator. http requests are done by
Site.PostData() or Site.getUrl() with gzip compression enabled by default.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-19 10:19
Message:
I also do not consume more time is good.
gzip compression will compress to about one-third of the text data.
Therefore, transfer time will be one-third. Is roughly.
However, data transfer has not been compressed in the generator.
This proposal is one way to solve this problem.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-19 09:48
Message:
It is less time consuming than loading e.g. 60 times each page separately.
What is the intention of this request?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3528259&group_…
Patches item #3529250, was opened at 2012-05-23 15:34
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3529250&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Jesse Weinstein (weinsteinj)
>Assigned to: xqt (xqt)
Summary: Fix userpageR regex
Initial Comment:
The existing regex for recognising links to userpages, userpageR, breaks if there are any extra attributes in the li or a elements. This patch fixes this.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-05-24 07:59
Message:
done in r10250. thanks.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3529250&group_…
Patches item #3529250, was opened at 2012-05-23 15:34
Message generated for change (Tracker Item Submitted) made by weinsteinj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3529250&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jesse Weinstein (weinsteinj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix userpageR regex
Initial Comment:
The existing regex for recognising links to userpages, userpageR, breaks if there are any extra attributes in the li or a elements. This patch fixes this.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3529250&group_…
Feature Requests item #3528259, was opened at 2012-05-19 09:38
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: xqt (xqt)
Summary: Do not use preloading in featured.py
Initial Comment:
Using the 'pagegenerators', data transfer is not compressed.
That data will be several megabytes.
That transfer is very time consuming.
Therefore, I think a good idea to remove that line.
Thank you consider.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-05-20 07:20
Message:
Maybe the header is wrong. I found 'Accept-encoding' as header parameter
but at https://www.mediawiki.org/wiki/API:Client_Code header is described
as 'Accept-Encoding' (capital Encoding)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 06:41
Message:
I was confirmed by Wireshark.
This is a packet analysis software.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 06:31
Message:
I don't know whether they are compressed or not. How did you see it?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 05:15
Message:
I understand. In the request header are described.
However, the response data are not compressed.
May be a bug of MediaWiki.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 02:04
Message:
This has nothing to do with preloading generator. http requests are done by
Site.PostData() or Site.getUrl() with gzip compression enabled by default.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-19 10:19
Message:
I also do not consume more time is good.
gzip compression will compress to about one-third of the text data.
Therefore, transfer time will be one-third. Is roughly.
However, data transfer has not been compressed in the generator.
This proposal is one way to solve this problem.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-19 09:48
Message:
It is less time consuming than loading e.g. 60 times each page separately.
What is the intention of this request?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Patches item #3528399, was opened at 2012-05-20 06:57
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3528399&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: rubin16 (rubin16)
>Assigned to: xqt (xqt)
Summary: fix of casechecker.py for ru.wiki
Initial Comment:
the original page-whitelist was deleted from ru.wiki, I've moved it to userspace and changed the script - it won't work without it
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-05-20 07:05
Message:
done in r10230. thanks.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3528399&group_…
Patches item #3528399, was opened at 2012-05-20 06:57
Message generated for change (Tracker Item Submitted) made by rubin16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3528399&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rubin16 (rubin16)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix of casechecker.py for ru.wiki
Initial Comment:
the original page-whitelist was deleted from ru.wiki, I've moved it to userspace and changed the script - it won't work without it
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603140&aid=3528399&group_…
Feature Requests item #3528259, was opened at 2012-05-19 09:38
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: xqt (xqt)
Summary: Do not use preloading in featured.py
Initial Comment:
Using the 'pagegenerators', data transfer is not compressed.
That data will be several megabytes.
That transfer is very time consuming.
Therefore, I think a good idea to remove that line.
Thank you consider.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 06:41
Message:
I was confirmed by Wireshark.
This is a packet analysis software.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 06:31
Message:
I don't know whether they are compressed or not. How did you see it?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 05:15
Message:
I understand. In the request header are described.
However, the response data are not compressed.
May be a bug of MediaWiki.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 02:04
Message:
This has nothing to do with preloading generator. http requests are done by
Site.PostData() or Site.getUrl() with gzip compression enabled by default.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-19 10:19
Message:
I also do not consume more time is good.
gzip compression will compress to about one-third of the text data.
Therefore, transfer time will be one-third. Is roughly.
However, data transfer has not been compressed in the generator.
This proposal is one way to solve this problem.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-19 09:48
Message:
It is less time consuming than loading e.g. 60 times each page separately.
What is the intention of this request?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Feature Requests item #3528379, was opened at 2012-05-20 04:31
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528379&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: ToAruShiroiNeko ()
Assigned to: Nobody/Anonymous (nobody)
Summary: redirect.py logging of problems that cannot be fixed
Initial Comment:
redirect.py needs to log issues it is unable to fix and why on each wiki. There are several flavors of problems that appears on Special:Doubleredirects
1. Self redirects (redirects that point to themselves)
2. Redirect loops (redirects that go in circles)
3. Double redirects formed due to page protection.
4. Inter-wiki redirects (redirects that point to redirects in other wikis)
It would be a lot easier if I had a log of these pages and user can post it on the village pump or perhaps bot can do this monthly for a select number of wikis. The code already provides a warning on the console but when you are running it on 700 wikis like me that becomes a serious chore to follow.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-05-20 06:36
Message:
1. - 3. are all listed by Special:DoubleRedirects. They are remaining after
the redirect bot cannot solve the problem.
4. Interwiki redirects normally are fixed be interwiki bots except there is
a __STATICREDIRECT__ in the redirect page.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528379&group_…
Feature Requests item #3528259, was opened at 2012-05-19 09:38
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: xqt (xqt)
Summary: Do not use preloading in featured.py
Initial Comment:
Using the 'pagegenerators', data transfer is not compressed.
That data will be several megabytes.
That transfer is very time consuming.
Therefore, I think a good idea to remove that line.
Thank you consider.
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-05-20 06:31
Message:
I don't know whether they are compressed or not. How did you see it?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 05:15
Message:
I understand. In the request header are described.
However, the response data are not compressed.
May be a bug of MediaWiki.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 02:04
Message:
This has nothing to do with preloading generator. http requests are done by
Site.PostData() or Site.getUrl() with gzip compression enabled by default.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-19 10:19
Message:
I also do not consume more time is good.
gzip compression will compress to about one-third of the text data.
Therefore, transfer time will be one-third. Is roughly.
However, data transfer has not been compressed in the generator.
This proposal is one way to solve this problem.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-19 09:48
Message:
It is less time consuming than loading e.g. 60 times each page separately.
What is the intention of this request?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Feature Requests item #3528259, was opened at 2012-05-19 09:38
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: xqt (xqt)
Summary: Do not use preloading in featured.py
Initial Comment:
Using the 'pagegenerators', data transfer is not compressed.
That data will be several megabytes.
That transfer is very time consuming.
Therefore, I think a good idea to remove that line.
Thank you consider.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-20 05:15
Message:
I understand. In the request header are described.
However, the response data are not compressed.
May be a bug of MediaWiki.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-20 02:04
Message:
This has nothing to do with preloading generator. http requests are done by
Site.PostData() or Site.getUrl() with gzip compression enabled by default.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-05-19 10:19
Message:
I also do not consume more time is good.
gzip compression will compress to about one-third of the text data.
Therefore, transfer time will be one-third. Is roughly.
However, data transfer has not been compressed in the generator.
This proposal is one way to solve this problem.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-05-19 09:48
Message:
It is less time consuming than loading e.g. 60 times each page separately.
What is the intention of this request?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3528259&group_…