https://bugzilla.wikimedia.org/show_bug.cgi?id=25984
--- Comment #10 from _Vi <[email protected]> 2012-06-10 04:20:05 UTC --- Actually it was not intended to merging into upstream, I implemented this primarily just for me to be able to grab online wikis, save them in compressed form and use local MediaWiki to view them, without any lengthy indexing phase. The result is at https://github.com/vi/wiki_dump_and_read ("wikiexport" is also a hacky hack). > Indent with tabs, not spaces. Is there patch checking utility to catch things and other common problems like on some other projects? > If you add a new global, it has to be defined in DefaultSettings OK. > Names like hackTriggered are fine for your code, but would carry no meaning if it were integrated upstream. As I don't know the MediaWiki internals, such attempts will alway be hacky unless "Bug 25984" really closed. Can rename to some proper things, but it will remain hacky. I usually explicitly mention the word "hack" to tell users "beware, something may be wrong here". > Instead of downloading from a web server, load from the filesystem. May be, but less flexible. The goal is to make easy to connect MediaWiki to other page source code source. HTTP approach is portable, with filesystem approach the only good way is FUSE. > Check for ../ attacks. It is job of the server. https://github.com/vi/wiki_dump_and_read/blob/master/wikishelve_server.py just serves entries from Python's "shelve" database (single file on filesystem). And the whole thing is initially intended for local-only read-only usage. > Wikipage::checkForDownloadingHack() should return itself the (cached) content, instead of manually doing the $this->downloadedContent Yes. > No need to hack Parser::fetchTemplateAndTitle(), that can be redirected through setTemplateCallback(). Not a PHP/MediaWiki hacker => just did what managed to do the first. > Why do you need to change EditPage, if you're not doing page editing? To be able to view source (sometimes things get broken => can still view content in source form). > Ideally, there would be different classes depending if it was db-backed or filesystem-based I think creating good class structure to support DBBackend, FilesystemBackend, HttpBackend is a step in resolving "Bug 25984". (Bumping this discussion was advised by Freenode/#mediawiki user) (Will tell here again if/when implement the improved fetch-from-HTTP patch) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
