Are there any hooks available planned that are called right before or
after article is displayed in HTML? They'd be useful to have around to
display HTML before or after the contents of an article.
Travis
On Thu, Jul 27, 2006 at 12:05:57AM -0600, Chad Perrin wrote:
> > Please don't construe this statement as a veiled snipe at PHP (or Java, or
> > any other language). It's just an observation of fact.
>
> I should help stab someone for choosing PHP, too, for that matter -- but
> we work with what we've got.
Unthreaded: in a clear field, Chad, what *would* you have implemented
MediaWiki in? And why?
(Thread-kill is your friendi, folks...)
Cheers,
-- jra
--
Jay R. Ashworth jra(a)baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
Fanfic: read enough, and you'll loose your mind. --me
I've found some nice classical ogg files online (CC-BY-SA-2.0). However,
some are larger than 20 MB. Uploading those leads me back to a blank
upload page, without comment or error. 20MB seems to be a magical limt
for PHP.
Is there a way to bypass that limit? I'd hate to have to cut perfectly
good ogg files.
Magnus
Is there a way to set to send out an email to sys op when a specific page
has been updated?
For example, I have a FAQ page which when a user adds in a question - I
would have to answer it on the wiki page.
Instead of checking it every now and then it would be so much better if the
page alerts me whenever there is a new edit.
Thank you
One significant potential source of error in Leon's (marvelous!)
new hitcount stats is the possibility that one reader is for
whatever reason fetching the same page multiple times (perhaps
due to nothing more than a prolonged edit).
Obviously it would be best to filter out multiple fetches of the
same page from the same IP address over some interval, probably
one day. (Yes, this could then undercount hits from behind NAT
firewalls and proxies, but I think it'd still be worth it overall.)
I know that Leon's scheme is currently not logging IP addresses,
and given AOL's recent high-profile screwup I have to agree that
not logging IP addresses in this context is probably a good idea.
But what if we logged a one-way hash of the IP address, that
couldn't be correlated with anything else?
Just a quick note; this fall we hope to have a system set up for sniffing page
hits out of the network traffic to the squids and producing aggregate statistics
from that.
In the meantime, I think we'd all appreciate a little less fighting in the
JavaScript hit counter threads. :)
This stuff is fun and useful but a) short-term and b) not that important wrt to
spoofing. If someone pings the counter on some page a lot, well... who really
cares? It's not as though we're doling out revenue based on hits.
-- brion vibber (brion @ pobox.com)
Hello developers,
could you please update those two system messages until the Election
begins (00:00 September 1, 2006, UTC)?
MediaWiki:boardvote_notqualified & MediaWiki:boardvote_notloggedin. On
all Wikimedia wikis, though personally I don't recommend you to vote
from a closed/not public wikis ...
It would be great, if you avoid override some newly updated version on
some projects, but overwritten might be better than having the
outdated version.
/me confesses the lack of foresight on this matter, (again) as techno-laity
... and not all wiki can be expected to be properly updated by sysop
hands. (I'm a pessimist in some occasions, don't you know?)
See also: http://meta.wikimedia.org/wiki/Election_UI_text_2006
Thank you for your help, always!
P.S. Or you perfer to get like the above on bugzilla? I am not sure on
your preferences ...
On 8/29/06, Tim Starling <tstarling(a)wikimedia.org> wrote:
> The board vote interface is going to be the same as last year, except
> for the requested change in qualifications. We now require that the
> first edit occurred more than 90 days before August 1, which by my
> calculations is May 3. I'm proposing that the boardvote_notqualified
> message is changed so that $4 is the date of the first edit and $5 is
> "May 3, 2006" in the user's language. Also, boardvote_notloggedin will
> have $3 available as "May 3, 2006". So the text could be:
>
> boardvote_notqualified: You are not qualified to vote in this election.
> You need to have made $3 edits before $2, you have made $1. Also, your
> first edit was at $4, it needs to be before $5.
>
> boardvote_notloggedin: You are not logged in. To vote, you must use an
> account with at least $1 contributions before $2, and with a first edit
> before $3.
>
> -- Tim Starling
>
--
Kizu Naoko
Wikiquote: http://wikiquote.org
* vivemus, mea Lesbia, amemus *
Hi,
Having trawled around the archives of this and some other lists and
searching for a couple of hours, I have read that MediaWiki
automatically merges simple edit-conflicts.
In practice using two separate setups (both Win32 - not my choice,
work only uses windows systems):
* MediaWiki: 1.7.1
* PHP: 5.1.6 (apache2handler)
* MySQL: 5.0.19-community
(apache 2.0.59 win32)
* MediaWiki: 1.6.5
* PHP: 4.4.2 (cgi-fcgi)
* MySQL: 5.0.19-community
(IIS)
..even very basic edits do not auto merge and throw an edit conflict.
By very basic edits I refer to changes made to completely different
lines in a small file.
Is this the intended functionality of this? I find it hard to believe
considering all the "automatic merging" discussion and information I
have seen. If not, why are my basic edits not auto merging? Do I need
to configure anything? Is it related to win32 installation?
Cheers in advance
-Tim
An automated run of parserTests.php showed the following failures:
Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test TODO: Template with thumb image (with link in description)... FAILED!
Running test Template infinite loop... FAILED!
Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test TODO: message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED!
Running test TODO: Inline HTML vs wiki block nesting... FAILED!
Running test TODO: Mixing markup for italics and bold... FAILED!
Running test TODO: 5 quotes, code coverage +1 line... FAILED!
Running test TODO: HTML Hex character encoding.... FAILED!
Running test TODO: dt/dd/dl test... FAILED!
Passed 412 of 429 tests (96.04%) FAILED!
Whoa! I missed the announcement of implementing the marvelous new
hitcounter. What happened to concerns about spoofing hits by way of
bypassing the sampling - is it a non-javascript thingy that is therefore
impervious to spoofing? I'd love to see the logic/code.
Just to add to the "logging hashed versions of ip addresses" fray: we could
recreate and overwrite the supersecret key daily (or even hourly). It then
occurs to me that you could theoretically use this, along with the stats of
consistently popular pages, to try to decrypt the hash, but that's gotta be
a fantastically difficult. You could further mix it up by changing the hash
every day (is that stupid? sounds like a good idea). Then, you could see
multiple views of a really popular page by the same guy (he'd have to have a
*lot* of views, to be picked up through the sampling rate). Any holes in
this logic? Fun to think about.
Regards,
Aerik