New Wiki #31
Labels
No labels
announcement
authentication
automate
aws
backlog
blocked
bodhi
ci
Closed As
Duplicate
Closed As
Fixed
Closed As
Fixed with Explanation
Closed As
Initiative Worthy
Closed As
Insufficient data
Closed As
Invalid
Closed As
Spam
Closed As
Upstream
Closed As/Will Not
Can Not fix
cloud
communishift
copr
database
deprecated
dev
discourse
dns
downloads
easyfix
epel
factory2
firmitas
gitlab
greenwave
hardware
help wanted
high-gain
high-trouble
iad2
koji
koschei
lists
low-gain
low-trouble
mbs
medium-gain
medium-trouble
mini-initiative
mirrorlists
monitoring
Needs investigation
notifier
odcs
OpenShift
ops
OSBS
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
rdu-cc
release-monitoring
releng
repoSpanner
request-for-resources
s390x
security
SMTP
src.fp.o
staging
taiga
unfreeze
waiverdb
websites-general
wiki
No milestone
No project
No assignees
9 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Infrastructure/fedora-infrastructure#31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Its time to investigate a new wiki. Moin just isn't cutting it. We need to
Determine what needs we have out of a wiki
Determine what wiki's are out there
Figure out if migration is possible
Proof of concept
Choose
Implement
I've been investigating [http://ikiwiki.info/ ikiwiki] for some personal use. It might be interesting to see if it'll work for Fedora. The main benefit is that it compiles the wiki markup into static pages, thus reading pages ought to be extremely fast. Josh Triplett has been working on [http://ikiwiki.info/index/discussion/#index2h1 converting a Moin to ikiwiki]. The main downside is that it's implemented in Perl...
[http://fedoraproject.org/wiki/Infrastructure/WikiRequirements here] is a start at defining the requirements for a new Wiki.
The discssion on requirements for a new wiki seems rather short-sited. Ruling out PHP because of a security track-record doesn't hold a lot of water IMO. Yes, PHP has a bad track-record, mostly due to poorly written applications that happen to have 'PHP' in the name, not the lanugage itself. Also, the top wikis in the world use Mediawiki (PHP) and we don't read headlines of them constantly being destroyed, hacked, or whatnot. The wiki should apply appropriate security controls and evaluations before being chosen. It shouldn't be "not this one because it uses foo."
I am just asking to be fair in the evaluation of product and not state bias in a requiments document.
Just an update to this ticket. We ended up choosing mediawiki for a number of reasons, all of which I'll link to (it was discussed on mailing lists (fedora-infrastructure-list) and in meetings.
i'm willing to help with whatever needs done. i have a significant amount of MediaWiki experience, especially with Wikitext syntax.
Here are a list of changes necessary to the communication script so far, in a sort of outline format:
A. Note/message/warning boxes needed to be fixed
{{{
{| border="1"
|<tableclass="message notice"> The Bugs/Common page is useful for finding fixes to already known issues. ||
|-
|}
}}}
{{{
{{message/notice|The Bugs/Common page is useful for finding fixes to already known issues.}}
}}}
A. (non-communication script) Clicking the Fedora logo on the wiki goes to /w/Index, which 404s. Should be changed to /wiki/Main_Page.
A. Internal links for some reason are being translated into sorta-kinda external links (for example, Main Page, shows 'Overview' as an external link to the wiki page Overview, instead of an internal link...)
{{{
[http://fedoraproject.org/wiki/Overview Overview] for a quick overview on what makes Fedora, Fedora.
}}}
{{{
Overview for a quick overview on what makes Fedora, Fedora.
}}}
A. tags fail. Check the !MediaWiki syntax on tables to fix this...
A. User pages (such as !IanWeller) should be moved to proper User namespaces (i.e.: User:Ianweller, if following FAS scheme)
A. !MailTo() needs to be fixed -- I recommend just changing it to 'ianweller AT gmail DOT com' format. Maybe there's an extension to do what Moin's !MailTo() does...
A. Every single attachment needs to be checked for duplicity, then 'uploaded' using a sane file name, and included using the following syntax:
{{{
}}}
{{{
}}}
A. Double backticks (``) need to be removed, there is no autolinking
A. Should emoticons and other symbols be fixed?
{{{
}}}
A. Take a look at [https://publictest1.fedoraproject.org/wiki/ConsensusProcess ConsensusProcess] ([http://fedoraproject.org/wiki/ConsensusProcess old wiki])...
A. Setup different namespaces for different languages
Also will we be dealing with spaces in page names, as in moving from no spaces to spacing? It's possible that changing the page name to what's in the level 1 header (= Level 1 header =) might work for most pages, however we'd probably lose the directory-like structure. shrug
This would also be a wonderful time to clean out pages that could be deemed useless. One way to look for these is see what pages are very short, or are not linked to at all...
A team probably needs to be created so that we can crawl the entire wiki manually and fix any mistakes we see in one surge, however I don't see this as being very plausible.
WOW, thanks for these markups.
no problem, let me know the next time you run the wiki through the communication script so i can keep looking for more problems.
a few design notes I want to make on the wiki --
A. quite a bit of stuff in the header seems out of place.
A. footer is all weird
also, i think the communication script can kill all the MoinEditorBackup pages. those pop up a lot when i hit 'random page'
redirects are broken... from what i can tell Moin uses a feature that denotes that on the page to be redirected to, while MediaWiki puts a redirect directive in the page that is to redirect to something else. I tried this on PackagingGuidelines, which redirects to Packaging/Guidelines...
also Anchor() functions should probably be removed. MW automatically makes anchors.
This actually won't get done in time for F9 but will happen shortly after.
Replying to [comment:18 ivazquez]:
For any HTML headers (
) in the Docs.* namespace, those are a workaround for the DocBook converter in Moin. Let's convert those in the script that are in the Docs.* namespace into the equivalent
foo
=> == foo ==.For HTML of IRC logs, maybe convert them to attachments and create a contents page?
Looking at the DocsProject pages conversion I see on wiki/DocsProject:
[http://docs.fedoraproject.org] became a 1 icon in MediaWiki. Not sure how much of this usage there is, but we need to convert that to a link that shows the URL, e.g. just a plain URL without brackets should suffice.
This is a legitimate Moin construct:
[http://opencontent.org/openpub Open Publication License]
It converted into MediaWiki syntax like this:
Open Publication License
Formatting on the page like this:
[Publication License]
... with a URL of http://opencontent.org/openpub|Open
Rather than convert the TableOfContents macro from Moin, just vaporize it. MediaWiki supplies a ToC automagically, halleluja!
Some general formatting items all bunched together:
I forgot, is there a manual anchoring construct in MW? If so, can we just have all Anchor() macros converted so things don't break or require a bunch of manual intervention? Then tell people to stop making new ones, etc.
Indented bulleted lists (ref. https://publictest1.fedoraproject.org/wiki/DocsProject/WorkFlow) are converting flat without nesting. If nesting is going to be lost ... we have to see how much is potentially lost. It might be easier to wrap all lists in <code /&rt; blocks and manually removing when fixing syntax. I think that'd be a better way than having to compare each page with each old page, back and forth. Better to have the proper thing inline and ready for manual fixin'.
People were taught to use the admonition graphics (/!\ etc.) and generally use these as admonitions in a consistent way. What if we defined a div class for them, then whenever the parser finds one of these image constructs, that line and any lines below until the first blank line are wrapped in a div specific to the image type. This would be consistent with how people do first and following lines with one of these images in an admonition. This would catch more true positives than leaving them alone.
Pages like these are getting wrapped in a pre tag:
https://publictest1.fedoraproject.org/wiki/Docs/Drafts/GettingStartedGuide
https://publictest1.fedoraproject.org/wiki/Docs/Drafts/SoftwareManagementGuide
https://publictest1.fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide
I reckon it's from the HTML call? Those aren't really needed, maybe the conversion of those HTML segments to standard = Wiki Header = format will help? Should we add those to a list of pre-conversion tasks to complete in Moin Moin?
WikiEditing is really the canonical source for how things look, so looking at the success and details of converting that page should cover most other pages, at least where they follow the WikiEditing conventions.
https://publictest1.fedoraproject.org/wiki/WikiEditing
Replying to [comment:24 kwade]:
... in particular, note how the formatting doesn't come through in the formatted examples here:
https://publictest1.fedoraproject.org/wiki/WikiEditing#Marking_Technical_Terms
The pre block goes awry here:
https://publictest1.fedoraproject.org/wiki/WikiEditing#Writing_Example_Commands
All the admonition styles are here:
https://publictest1.fedoraproject.org/wiki/WikiEditing#Notes.2C_Tips.2C_and_Other_Boxed_Text
Note that there have been some updates to the source WikiEditing page since this test conversion was done.
Here are a few things I've found so far that are not quite there. Thanks for all your hard work on this!!!
Table conversion needs help: https://publictest1.fedoraproject.org/wiki/DocsProject/Schedule
Section headings seem overly large in comparison to the associated text
handling of embedded html doesn't work
a. the table listing all of the features is missing
b. at the bottom of the page it suggests a category of "Category: AcceptedFedora9 (alpha order)" which is not correct. See item 3 above as it relates to the AcceptedFedora9 category.
Replying to [comment:26 poelstra]:
I think ianweller is working on getting these up and going. Once I can see how its supposed to look like in mediawiki I can convert them.
This should be fixed now (including the weird MoinEditorBackup thing). I haven't done a full upload yet.
I think these are related to 1) and 2)
Now working... but I'm not that happy with the formatting. I'll keep working on that.
Fixed but with poor formatting (I'll work with ianweller on this)
Thats css stuff which I think will be worked on.
This is related to - https://fedorahosted.org/fedora-infrastructure/ticket/270 and won't be enabled in the future after the migration (there are security concerns)
I think this was related to a failed import attempt. It should be in better shape now (please verify)
Interesting. After clicking on the category and actually creating the page, it no longer does this. I'm not sure how to make mediawiki do this automatically but will look into it.
Hmm, yeah thats not right. I'll take a look there.
Ok, number 14) was stale data and should be fixed. i've been having a problem I didn't notice before but it seems that when I sync the production copy with whats in test for manipulation the rsync is timing out. I'm looking at that now.
I'm working on that.
13:19 < quaid> https://publictest1.fedoraproject.org/wiki/Main_Page
13:19 < quaid> Image:Important.png
13:20 < mmcgrath> ah, thats something ianweller is working on. He hasn't uploaded that
image yet.
13:20 < quaid> in that case, it comes from the CSS
13:20 < quaid> <tableclass="message notice">
13:20 < mmcgrath> https://publictest1.fedoraproject.org/wiki/Artwork/DesignService <-- is a
good example of images coming up.
13:20 < quaid> I think this is a CSS then
13:21 < mmcgrath> nope, this is just that the images haven't been uploaded.
13:21 < mmcgrath> <tableclass="message notice" has been converted to a template {{
Template:message/notice }}
13:21 < mmcgrath> {{ Template:message/notice | The Bugs/Common
page is useful for finding fixes to already known issues. ||
13:21 < mmcgrath> }}
13:21 < mmcgrath> for example
Replying to [comment:18 ivazquez]:
This seems to still be an issue, in e.g. https://publictest1.fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide .
Replying to [comment:31 ivazquez]:
k, should be fixed. Please confirm
Replying to [comment:32 mmcgrath]:
The : is no longer there, but now the content is flush against the left.
More pages not converted properly: all the fonts SIG pages.
For example:
https://publictest1.fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline
I may have missed a few convertion errors on that page
Replying to [comment:34 nim]:
Its likely this won't happen and will require manual intervention.
Replying to [comment:35 mmcgrath]:
Yup. I'll come up with a banner template, and then we can do something like {{banner/docs}} for the docs template, or what have you. Maybe I can get this done today or tomorrow.
I found that some links aren't being converted correctly... probably because Moin has several valid syntax's for specifying links. Here's the formats I've found that aren't being converted:
{{{
[wiki:Self:Development/SteeringCommittee Fedora Steering Committee (FESCo)]
["Packaging/Minutes"]
}}}
Examples on: https://publictest1.fedoraproject.org/wiki/Packaging/Committee#Step_Two:_Packaging_Committee_Review
MailTo() macros need fixed.
I noticed that the URL doesn't work without the final slash. Can this be fixed before production switchover?
http://fedoraproject.org/wikinew == doesn't work
http://fedoraproject.org/wikinew/ == does work
Closing this ticket. The /wikiold stuff does work properly now. As future issues come up please put them in a new ticket.