There is 667 articles in the list. Checked is 167, or 25% .
The bug that is blocking new wiki infrastructure setup (templates, namespaces, help files) is still preset.
Problem is that important tool CategoryTree doesn't work for visitor (non logged in user) and logged in users that are not administrators.
The main tool FlaggedRevs works fine as Frank fixed problem with css and now it shows just as it should.
On Saturday 23 January 2010 08:33:41 Rajko M. wrote:
Hi,
The bug that is blocking new wiki infrastructure setup (templates, namespaces, help files) is still preset.
Problem is that important tool CategoryTree doesn't work for visitor (non logged in user) and logged in users that are not administrators.
It also affects ParserFunctions.
the problem is that we do not have the slightest clue what is causing this problem. What makes things more complicated is the fact that it sometimes works, although most of the time not.
I have set up a test wiki using the same config and the same set of extensions as wiki.o.o and the problem did _not_ occur. I even asked on the MediWiki mailinglist but received no answers.
So fixing the problem will most probably take longer... .
On the other hand I do not think it should hinder the transition at all, since all of you need to be logged in anyway. So as long as we do not make wiki.o.o officially available for the public, this problem does not affect our work.
Hi,
On 25.01.2010 11:35, Frank Sundermeyer wrote:
On Saturday 23 January 2010 08:33:41 Rajko M. wrote:
The bug that is blocking new wiki infrastructure setup (templates, namespaces, help files) is still preset.
On the other hand I do not think it should hinder the transition at all, since all of you need to be logged in anyway. So as long as we do not make wiki.o.o officially available for the public, this problem does not affect our work.
Yes i agree. Lets go! Rajko as far as i can remember you are okay with removing all the pages right you have added in the main namespace right? I volunteer to do that. What about the other namespaces? Template: and so on?
Henne
On Monday 25 January 2010 06:11:58 Henne Vogelsang wrote:
Yes i agree. Lets go! Rajko as far as i can remember you are okay with removing all the pages right you have added in the main namespace right? I volunteer to do that. What about the other namespaces? Template: and so on?
You can let someone that can run scripts to run nukePage.php on following pages:
25 Numbered subpages Acronyms Additional Package Repositories Add Package Repositories AutoYaST Avogadro BIOS Blah BlueJ Boot Loader BugDays/20080425 Bugs/YaST Building YaST components Canorus Chemtool Childsplay Console Creating customized installation source Creating YaST Installation Sources Development Version Dosbox Dosemu Download Download Help Drgeo Easy-LTSP Easy-LTSP/GSoC Ideas Education Education/Applications Education/Applications/Best Of Education/Applications/Desktop Education/Applications/Desktop/Ages 12-18 Education/Applications/Desktop/Ages 4-12 Education/Applications/Desktop-old Education/Applications/Desktop Temp2 Education/Applications/Server Education/Communicating Education/Development Education/Development/Edu-CD Education/Development/Edu-CD/Roadmap Education/Development/Roadmap Education ERP Education/Live Education/Live/Install Education/Live/Screenshots Education/opensuse-education-roadmap Education/Participating Education/Planning Education/Press Education/Repositories Education/Roadmap Education/Team Education/To do Education/Wiki Education/Wiki/Roadmap Edu-standards EXelearning FBReader FET Gambas Gbrainy GCompris Geogebra GNS3 GRAMPS GUI Gweled Hard Disk How Does KIWI-LTSP work HTML Ignuit Installation Help Italc Kding Kiosktool Klavaro Kolorpaint Kseg Ksociograma KSociograma Libzypp/Products/Add-On Libzypp/Products/DuD Libzypp/Products/DuD/Hardware Libzypp/Products/DuD/Installation Libzypp/Products/DuD/Starting Libzypp/Products/DuD/Update Linuxrc Littlewizard Logging YaST to USB Stick in Installation Main Page Manual Pages Maxima Mirrorbrain Moodle MultiplicationStation Octave OpenSUSE Wiki Welcome Package Repositories Pattern Metadata YaST Patterns Perl Piklab Portal Test Portal Test/box-footer Portal Test/box-header Portal Test/Categories Portal Test/Did you know Portal Test/Intro Portal Test/News Portal Test/Opentask Portal Test/Related portals Portal Test/Selected article/1 Portal Test/Selected article/2 Portal Test/Selected article/3 Portal Test/Selected article/4 Portal Test/Selected article/5 Portal Test/Selected picture/1 Portal Test/Selected picture/2 Portal Test/Selected picture/3 Portal Test/Selected picture/4 Portal Test/Selected picture/5 Pysycache Python-visual Qtractor Released Version Scilab Score-reading-trainer Semantik Software Vocabulary Standards/YaST2 Repository Metadata/media Standards/YaST2 Repository Metadata/packages Standards/YaST2 Repository Metadata/pattern Stardict SuSEconfig Tab Width Test TestSMW Tuxmath TuxMathScrabble Tuxpaint TuxWordSmith Updating openSUSE Vocabulary Wishlist Education XML YaST YaST Autoinstallation module YaST Build Environment YaST CD-ROM Drives module YaST CIM YaST common development problems YaST crashes YaST Date and Time module YaST debugging YaST default interface YaST development mailing lists YaST development overview YaST Disk Controller module YaST documentation YaST Education module YaST events YaST IDE DMA Mode module YaST Infrared Device module YaST Joystick module YaST Kdump module YaST Kerberos Client module YaST Keyboard Layout module YaST locale YaST Media Check module YaST modules YaST Mouse Model module YaST NTP Client module YaST old development YaST Online Update module YaST Patch CD Update module YaST porting projects YaST Post a Support Query module YaST SVN branches YaST user interface future YaST Workshop Prague 2007 YaST Workshop Prague 2007/Day 1 YaST Workshop Prague 2007/Day 2 YaST Workshop Prague 2007/Day 3
I'm not sure how to nuke pages that are already deleted.
Hello,
on Montag, 25. Januar 2010, Frank Sundermeyer wrote:
On Saturday 23 January 2010 08:33:41 Rajko M. wrote:
[some extensions not working for non-logged in visitors]
the problem is that we do not have the slightest clue what is causing this problem. What makes things more complicated is the fact that it sometimes works, although most of the time not.
I have set up a test wiki using the same config and the same set of extensions as wiki.o.o and the problem did _not_ occur. I even asked on the MediWiki mailinglist but received no answers.
Can you post the list of extensions that are used on wiki.o.o? (the include/require lines from LocalSettings.php should do)
I'm afraid that the iChain authentification could be the problem because only this extension is specific to the openSUSE wiki. - Did your test wiki use iChain also? - Does wiki.o.o work if you temporary remove the iChain login extension? (delete all cookies before testing!) - Did a mediawiki expert ever review the code of the iChain extension? (Is this extension public at all?)
The other thing that is special to the openSUSE wiki is the skin. In theory it could also cause the problem (even if chances are low) - did your test wiki use the openSUSE skin?
Regards,
Christian Boltz
Hello,
Here are the extensions and options for them. Thank you for cleaning this section up, Frank. I don't think I would call myself an expert on MediaWiki, but I have pored through the iChain authentication extension code while looking at the wiki.o.o login bug (it's fixed by the way), and it looks pretty solid to me. It is possible that it could be related to the wiki.o.o login bug, since that did require some changes to index.php. I will test this out and see if I can still see the problem.
##### Extensions #####
# Intersection --------------------- include("$IP/extensions/intersection/DynamicPageList.php");
# SimpleFeed ----------------------- include("$IP/extensions/SimpleFeed.php");
# iChain --------------------------- require_once("$IP/extensions/iChainAuthenticationPlugin.php"); $wgAuth = new iChainAuthenticationPlugin();
# InputBox ------------------------- require_once($IP.'/extensions/InputBox/InputBox.php');
# FlaggedRevs ---------------------- include_once("$IP/extensions/FlaggedRevs/FlaggedRevs.php"); $wgFlaggedRevsNamespaces = array(NS_MAIN, NS_IMAGE, NS_TEMPLATE, 100, 102); // SDB, Portal $wgSimpleFlaggedRevsUI = true; $wgFlaggedRevComments = true; $wgFlaggedRevsLowProfile = false; $wgFlaggedRevTabs = false;
# ParserFunctions ----------------- require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );
# CategoryTree.php ---------------- require_once("$IP/extensions/CategoryTree/CategoryTree.php");
# EventCountdown ------------------ require_once("$IP/extensions/EventCountdown.php");
# SemanticMediaWiki --------------- $smwgNamespaceIndex=120; include_once("$IP/extensions/SemanticMediaWiki/includes/SMW_Settings.php"); enableSemantics('wiki.opensuse.org');
# MultiBoilerplate ---------------- require_once( "$IP/extensions/MultiBoilerplate/MultiBoilerplate.php" );
Matthew Ehle Web Engineer
Novell SBU Application Development & Maintenance Office Phone: (801) 861-2722
Christian Boltz opensuse@cboltz.de 1/25/2010 6:47 AM >>>
Hello,
on Montag, 25. Januar 2010, Frank Sundermeyer wrote:
On Saturday 23 January 2010 08:33:41 Rajko M. wrote:
[some extensions not working for non-logged in visitors]
the problem is that we do not have the slightest clue what is causing this problem. What makes things more complicated is the fact that it sometimes works, although most of the time not.
I have set up a test wiki using the same config and the same set of extensions as wiki.o.o and the problem did _not_ occur. I even asked on the MediWiki mailinglist but received no answers.
Can you post the list of extensions that are used on wiki.o.o? (the include/require lines from LocalSettings.php should do)
I'm afraid that the iChain authentification could be the problem because only this extension is specific to the openSUSE wiki. - Did your test wiki use iChain also? - Does wiki.o.o work if you temporary remove the iChain login extension? (delete all cookies before testing!) - Did a mediawiki expert ever review the code of the iChain extension? (Is this extension public at all?)
The other thing that is special to the openSUSE wiki is the skin. In theory it could also cause the problem (even if chances are low) - did your test wiki use the openSUSE skin?
Regards,
Christian Boltz
On Monday 25 January 2010 14:47:46 Christian Boltz wrote:
Hi,
[some extensions not working for non-logged in visitors]
I'm afraid that the iChain authentification could be the problem because only this extension is specific to the openSUSE wiki.
very good shot, Christian! Matt and me were able to identify the iChain plugin (so Rajko, it's not iChain itself ;-) as being the source of the problem - it does not occur when disabling it.
So all we need to do now is to start another round of debugging that plugin... .
On Tuesday 26 January 2010 02:00:43 Frank Sundermeyer wrote:
(so Rajko, it's not iChain itself ;-)
It is something that has to do with it :)
I don't have it and my local wiki version 1.15.1 works fine with some of the extensions taken from the Mediwiki trunk few weeks ago. So called appropriate version that should be used with 1.15.1 makes wiki to bail out with error message about returned value that should be true or false.
2010/1/25 Frank Sundermeyer fs@suse.de:
On the other hand I do not think it should hinder the transition at all, since all of you need to be logged in anyway. So as long as we do not make wiki.o.o officially available for the public, this problem does not affect our work.
+1, but .. doesn't that will become a showstopper at some point in time? I mean, at some point in time we WILL release this to the public and everything needs to work for both logged-in and logged-out users.
Thanks for clarification, R
-- Regards Frank
Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
On Monday 25 January 2010 09:14:01 Rupert Horstkötter wrote:
+1, but .. doesn't that will become a showstopper at some point in time? I mean, at some point in time we WILL release this to the public and everything needs to work for both logged-in and logged-out users.
That problem will be solved. My favorites supect is iChain, as there is another problem with current login process that curbs use of standard wiki tools to fight spammers, but that is another story.
Rush is not good.
Just check the: http://en.opensuse.org/Transition_guidelines
* Should we use categorytree instead of navbar templates ?
My answer is that as long as we don't know properties of that tool, we can't answer the question. My experiment with Category tree was just basic setup to see is it working at all.
* Categorization - whole paragraph shows confusion: 1. we have no control over categories, anyone can add some 2. we can define only basic category tree layout
For both we can't predict what will be needed, or push articles in certain category, just to have it categorized. Categories are like keywords, there will be as many as it is needed.
All we can do is to remove duplicates that use synonyms, and change too specialized, or obscure category names to more common, easier to find.
* Templates (Just as normal articles, or categories) There will be as many as it is needed. All we can do is to prevent layout charade of templates that do the same with different layout, which is already done, bring existing templates in line with general usability rules for web pages that are free available on http://useit.com and keep new creations in line with that.
* Structure Not close to be known. Discussion about namespaces is not done. I promised the list, but the work doesn't go very fast. There is a lot to see around, find some software that can help sorting out current fond of articles.
My opinion on namespaces is that is better to have few more and allow users to use targeted search as it is presented in http://en.opensuse.org/SDB:SDB then to have to little and start cramming stuff in available namespaces as it is now.
Search (InputBox) is not the only extension that can be limited to certain namespace, so we gain better flexibility applying extensions that one project needs and the other not.
Bedside existing, I would add: KDE GNOME YaST Artwork News ....
The problem to find articles with default search in Main namespace can be solved: - with portal pages, that will contain list of articles that user can browse and search for particular namespace. - instructions to user how to enable search in user preferences - site map
Rajko M. wrote:
On Monday 25 January 2010 09:14:01 Rupert Horstk�tter wrote:
+1, but .. doesn't that will become a showstopper at some point in time? I mean, at some point in time we WILL release this to the public and everything needs to work for both logged-in and logged-out users.
That problem will be solved. My favorites supect is iChain, as there is another problem with current login process that curbs use of standard wiki tools to fight spammers, but that is another story.
Rush is not good.
Just check the: http://en.opensuse.org/Transition_guidelines
- Should we use categorytree instead of navbar templates ?
My answer is that as long as we don't know properties of that tool, we can't answer the question. My experiment with Category tree was just basic setup to see is it working at all.
- Categorization - whole paragraph shows confusion:
- we have no control over categories, anyone can add some
- we can define only basic category tree layout
For both we can't predict what will be needed, or push articles in certain category, just to have it categorized. Categories are like keywords, there will be as many as it is needed.
All we can do is to remove duplicates that use synonyms, and change too specialized, or obscure category names to more common, easier to find.
- Templates (Just as normal articles, or categories)
There will be as many as it is needed. All we can do is to prevent layout charade of templates that do the same with different layout, which is already done, bring existing templates in line with general usability rules for web pages that are free available on http://useit.com and keep new creations in line with that.
- Structure
Not close to be known. Discussion about namespaces is not done. I promised the list, but the work doesn't go very fast. There is a lot to see around, find some software that can help sorting out current fond of articles.
My opinion on namespaces is that is better to have few more and allow users to use targeted search as it is presented in http://en.opensuse.org/SDB:SDB then to have to little and start cramming stuff in available namespaces as it is now.
Search (InputBox) is not the only extension that can be limited to certain namespace, so we gain better flexibility applying extensions that one project needs and the other not.
Bedside existing, I would add: KDE GNOME YaST Artwork News ....
The problem to find articles with default search in Main namespace can be solved:
- with portal pages, that will contain list of articles that user can browse
and search for particular namespace.
- instructions to user how to enable search in user preferences
- site map
sorry for so much negativity from apparently a single source, but i have some experience in such things and it seems to me that what has happened here is a transition schedule was crafted without really knowing either the full task at hand, all the decisions needing to be made, or the number/capability of hands to do the work..
consequently i see in the above posting (and some others delivered with my [european schedule] morning coffee a whole host of still unanswered questions, uncoordinated and approved courses of actions and those pesky little details that can derail the train from engine to caboose..
yet, "we" (and i use that term very loosly) continue to discuss the details of which way we wanna go while the train is passing (maybe never to pass by again) track switches and grade crossings with names like "this bug is a showstopper" and "run scripts to run nukePage.php" or the hands off "This article has been reviewed!"
i'm probably wrong (and this may tread on the toes of good folks who should be encouraged to "press on" rather than what is about to come) but, it seems to me that this transition requires the concentrated effort of a number of disciplines like [but not limited to these three]: 1) technical wizards/hackers to *force* the wiki program itself to 'serve' us, rather than the other way around; 2) process/project planners, coordinators, managers, leaders, yes even mentors to formulate and execute the complicated plan needed to *force* the _whole_ train to the destination; 3) writers, editors, word warriors, quality assurance checkers and etcetera to *force* the prose on board at destination to convey the 'correct technical info' with as little chance of being misunderstood by (various levels of english & technical proficiency) _*USERS*_ as possible..
from what i've seen (and i'm fully aware i may be completely wrong--having actually seen very little of the process, and having seen NONE of the goings on prior to about mid-December) it *seems* to me that the Discipline One folks drove the train at near full speed in the general direction of the destination until the other disciplines were needed to actually do the work, and then held an IRC "mentoring session" to kick off the coasting in, smooth ride to Nirvana....with the arrival expected to be (when?) about now..
yet, "we" arrive at 'now' without having the *executable* plan of where we wanna be fully mature..
[and now, morning coffee finished, i waddle off to forums.opensuse to try to help yet another first time poster/troll with his/her "how do i change the background?? i logged into KDE as root and STILL it won't let me...SuSe SuX!....Waaaaaaa...i'm going back to Vista!!]
peace (remember i wrote it all not to step on toes, but instead trying to be a little helpful), DenverD
Rajko,
thanks for all this valid input. In order to solve the concerns you mentioned, may you start several threads addressing these issues? That way we concentrate on one issue per thread and seek a solution. That said, I'd appreciate if you'd take the lead in pushing this forward and document a solution (as soon as we have it) as you seem to be the person in our team with the most insight into mentioned topics.
Aligned?
Best, R
2010/1/26 Rajko M. rmatov101@charter.net:
On Monday 25 January 2010 09:14:01 Rupert Horstkötter wrote:
+1, but .. doesn't that will become a showstopper at some point in time? I mean, at some point in time we WILL release this to the public and everything needs to work for both logged-in and logged-out users.
That problem will be solved. My favorites supect is iChain, as there is another problem with current login process that curbs use of standard wiki tools to fight spammers, but that is another story.
Rush is not good.
Just check the: http://en.opensuse.org/Transition_guidelines
- Should we use categorytree instead of navbar templates ?
My answer is that as long as we don't know properties of that tool, we can't answer the question. My experiment with Category tree was just basic setup to see is it working at all.
- Categorization - whole paragraph shows confusion:
1. we have no control over categories, anyone can add some 2. we can define only basic category tree layout
For both we can't predict what will be needed, or push articles in certain category, just to have it categorized. Categories are like keywords, there will be as many as it is needed.
All we can do is to remove duplicates that use synonyms, and change too specialized, or obscure category names to more common, easier to find.
- Templates (Just as normal articles, or categories)
There will be as many as it is needed. All we can do is to prevent layout charade of templates that do the same with different layout, which is already done, bring existing templates in line with general usability rules for web pages that are free available on http://useit.com and keep new creations in line with that.
- Structure
Not close to be known. Discussion about namespaces is not done. I promised the list, but the work doesn't go very fast. There is a lot to see around, find some software that can help sorting out current fond of articles.
My opinion on namespaces is that is better to have few more and allow users to use targeted search as it is presented in http://en.opensuse.org/SDB:SDB then to have to little and start cramming stuff in available namespaces as it is now.
Search (InputBox) is not the only extension that can be limited to certain namespace, so we gain better flexibility applying extensions that one project needs and the other not.
Bedside existing, I would add: KDE GNOME YaST Artwork News ....
The problem to find articles with default search in Main namespace can be solved:
- with portal pages, that will contain list of articles that user can browse
and search for particular namespace.
- instructions to user how to enable search in user preferences
- site map
-- Regards Rajko,
openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
Hi,
On Monday 25 January 2010 16:14:01 Rupert Horstkötter wrote:
2010/1/25 Frank Sundermeyer fs@suse.de:
On the other hand I do not think it should hinder the transition at all, since all of you need to be logged in anyway. So as long as we do not make wiki.o.o officially available for the public, this problem does not affect our work.
+1, but .. doesn't that will become a showstopper at some point in time? I mean, at some point in time we WILL release this to the public and everything needs to work for both logged-in and logged-out users.
this bug is a showstopper, no doubt about that. I didn't intend to say we will not fix it, but rather "We will try to fix this bug as soon as possible. In the meantime, go on with the transition as planned, because this bug is non- critical in this phase of the transition."
-
Christian Boltz -
DenverD -
Frank Sundermeyer -
Henne Vogelsang -
Matthew Ehle -
Rajko M. -
Rupert Horstkötter