Hello,
I am looking into the possibility of merging two wiki's with each other I would like to know if it is possible to actually merge the databases or that a Special:Export <> Special:Import would work. (What happens with Import/Export when a page already exists?) Is there even a way to export (and import) the *entire* wiki?
I know I could run all the wiki's side by side and create interwiki links to create something similar, but that doesn't integrate the search function.
Hans Voss wrote:
I am looking into the possibility of merging two wiki's with each other I would like to know if it is possible to actually merge the databases or that a Special:Export <> Special:Import would work. (What happens with Import/Export when a page already exists?)
The history would contain all edit on the page names from both wikis mixed together.
Is there even a way to export (and import) the *entire* wiki?
cd /bla/firstwiki/maintenance php dumpBackup.php --full > /tmp/firstwiki.xml
cd /bla/secondwiki/maintenance php importDump.php /tmp/firstwiki.xml
(These are new in 1.5.)
-- brion vibber (brion @ pobox.com)
Ahem: I dont do the bugzilla thing, so Ill just file this here --a feature request I suppose (more just an idea) and people stick it where they like.
Multi-diff-view history proposal
Alternate view of article histories as showing multiple diffs in a single page. Unlike current history, multi-diff will show only the actual edited paragraph without any surrounding context (to save space). For obvious reasons I think this will make it easier to track sneaky vandalism, and perhaps even help bring more oversight to revert warring.
Also unlike the current diff view, each version will contain article and edit links to each version. Scolling down will scroll through the history, showing the relevant (changed) material for an arbitrary number of back-edits.
Views can be based on a "last 10", "last 20", etc. approach, and when in a historical diff version, a "prev 10" "prev 20", "later 10", "later 20". Sorting on the basis of minor edits, and even diff size might also be possible. SV
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I dont do the bugzilla thing, so Im filing this here, with no expectation or requirement for feedback.
Page protection currently is limited to either no protection or protection against all but sysops. Policy places strict limitations on sysop edits of protected pages.
A second tier of protection may be useful, if it allows for edits by logged-in users only. This would be equivalent to a Localsettings.php requiring log-ins for all edits, only particular for each page. This could provide for some gradation in how protection is applied, and save some hassles regarding an the current on-off system.
SV
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
steve v wrote:
I dont do the bugzilla thing, so Im filing this here, with no expectation or requirement for feedback.
Page protection currently is limited to either no protection or protection against all but sysops. Policy places strict limitations on sysop edits of protected pages.
A second tier of protection may be useful, if it allows for edits by logged-in users only. This would be equivalent to a Localsettings.php requiring log-ins for all edits, only particular for each page. This could provide for some gradation in how protection is applied, and save some hassles regarding an the current on-off system.
In 1.5, there is group-based control for actions. The 1.5 DB schema seems to support per-page restrictions (not sure if/how MW supports this).
And the logged-in to edit was implemented as an option back in 1.3, I think.
-- Jamie ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.
On 9/15/05, steve v vertigosteve@yahoo.com wrote:
I dont do the bugzilla thing, so Im filing this here, with no expectation or requirement for feedback.
If you care about a feature idea, do the footwork to at least see if there have been similar requests. Then you can back an existing request.
Developers quite literally do not care about mailing lists for collecting ideas. If it doesn't show up in their bug tracker it'll never be seen by the people who matter to a feature.
It's people like me who might grab interesting ideas for filling a report with, but it's a slap in the face when someone specifically opts out of adding it themselves.
In this particular case, security has been a long-discussed issue. I'm rather interested in it myself. Of note, the team has very specific opinions of it which have shaped the way security "works" for MediaWiki. I'm sure their minds won't be changed in this way.
Sigh..
mediawiki-l@lists.wikimedia.org