Thanks Paul,
I experience your contribution (below) as coming from a real straight shooter, concise, well thought out and thoughtfully presented, and based on your own experience. What more can I ask? Thank you very much. I find your insights informative and very useful, perfectly said and presentable to my boss when asking for money, "See, I'm not the only one needing support for a wiki in$tallation!" Thanks also for the recommendation of "Jim Wilson, can't recommend him enough!" I now know better where you're coming from, and I feel better informed to take what you have learned and shared, and adapt and adopt it to my own situation.
Me? I use Intuit Quicken for DOS from the 1980s (fits on one floppy). It's an incredibly sophisticated relational database. I see multiple bank accounts in the same database as I see multiple wikis on one MySQL. I see transfers between bank accounts as I see shared resources in groups of wikis. I see Quicken's multiple levels of categories and classes as extremely intelligent for sorting and selecting, making reports, and changing them globally on the fly as I see ... wait a minute, media wiki's categories aren't very powerful, and there are no classes. Quicken looks ahead of my typing for anything, and suggests matches, and offers to create anything new I type without having to exit from the immediate data entry task to reconfigure anything. MediaWiki allows quick page building the same way, but scant little else. In my Quicken, backup and restore, creating new databases and new accounts, and reconfiguring the whole program are simple, I even backup to an email attachment and save it on the web, program and all. MediaWiki has none of these features for the whole program, for just your data, or even just your custom configurations. Like open source programmers, the people who designed Quicken were paid nothing at the time (one difference, though, the paper stock Quicken-designers were paid with turned out to be worth $14,000 an hour when Intuit finally went public!).
My point is that 20 years ago, many of the things I expect in any modern, sophisticated software were already well worked out and well established. And I'm not even talking about Word Perfect or Lotus 1-2-3. I'm sad that the folk in today's open source community are trying to ride two horses at once - a day job for the rent, and a night job trying to help their open source baby (or hold the reigns on what should belong to everyone). Yet, they are not standing on the shoulders of those who came before them in the arena their customers are begging them to enter. Is MediaWiki the new FORTRAN, only for programmers and support staff, or is MediaWiki the new Netscape Navigator/ Communicator/Messenger/Composer, for everyone?
I guess it's 2 cents time. Thank you for yours. That's mine.
Anybody else? Where are you coming from and going to with your MediaWiki experience?
-- Peter Blaise
=== quotable ===
Paul wrote: ... I have read many of the messages on the list of the last few weeks and resisted jumping in until I saw whether you were going to find some untapped vein of knowledge or, more likely, you would need to do a lot of the legwork yourself with hints and near answers. I do find this mailing list VERY useful but typically not because I get the exact answer I need but more usually because it sends me off in the right direction to find it myself. This is fine with me and I have learnt a ton in the last 3+ months with help from some of the regular posters here. The lack of comprehensive documentation, setup instructions or the like whilst being somewhat frustrating is something that playing with MediaWiki you have to learn to accept, for now. I really don't know anyone that has the time to devote to building the type of documentation you are looking for BUT I do suspect that if sponsorship were available there would be candidates. ... sponsorship of an open source project from ... an organization would be interesting indeed. This isn't to say that people are only motivated solely by money but they have to pay their bills which personally I find absolutely fine. I myself needed some extensive changes made to the Mediawiki UI and after spending a few days looking I realized that Mediawiki is a complete beast when it comes to the construction of the UI and it's associated CSS. I took the admittedly easy way out and simply got an expert (Jim Wilson, can't recommend him enough!) to author a custom skin (www.scribas.com/archives which does everything we need. The site is currently in stealth mode and offline but you get a feel for what it will look like. The easier parts of Mediawiki, for me, have always been the data driven components. Data is data is data and so I have been able to change pretty much whatever I want by virtue of the fact that the data is stored in a known and well documented system, MySQL. Actually, on that note we are soon to be looking to migrate the index from MySQL to Lucene for fast cross-site searching/indexing of Mediawiki and Drupal. Anyway, the reason for my post. I could be way off track here but I suspect that a lot of the, admittedly logical, requests you have generated whilst being perfectly reasonable within the black box, vendor supported world are just a little ahead of their time in the Mediawiki/open source world. Be it Drupal, Wordpress, Joomla, Mediawiki, or whatever open source project I think you will always hear gripes about the documentation and feedback in the event of bug/problem. I don't think mediawiki is any worse or better in this regard and in fact having tested three other wikis I would say it is without doubt the most solid out there. So...the solution? I don't think there is one in the short term. As much as I would love to see comprehensive documentation I wont be holding my breath. Instead, I research, ask questions and generally make progress with help from this mailing list. Ideal? No, but you pays your money and takes your choice. I could have gone to socialtext and got a fully supported wiki but the cost would have been significant. Mediawiki is 'free' but comes with a sometimes costly lack of support framework. Oh, and the reason, in my humble opinion, for the fact that you see several names for the same entity is possibly quite simple. There are hundreds of contributors, each using slightly different phraseology. Regards, Paul
[more on Scribas visual design at http://webdesign.parkertorrence.com/zfrog/portfolio/scribas/ ]
Frankly I can't work out your problem. You hark on a lot about how great things were, or are, in other software, and other little asides, but rarely do you actually pose a specific question. The ways I learnt about MediaWiki are a) using Wikipedia, b) experimenting - trial & error, c) this mailing list and lastly and most recently, the book mentioned on this list, which I was given a review copy of.
I appreciate you (seem to be) installing MediaWiki on your own Windows server, which is clearly more complex than the shared hosting I use.
On 06/06/07, Monahon, Peter B. Peter.Monahon@uspto.gov wrote:
Thanks Paul,
I experience your contribution (below) as coming from a real straight shooter, concise, well thought out and thoughtfully presented, and based on your own experience. What more can I ask? Thank you very much. I find your insights informative and very useful, perfectly said and presentable to my boss when asking for money, "See, I'm not the only one needing support for a wiki in$tallation!" Thanks also for the recommendation of "Jim Wilson, can't recommend him enough!" I now know better where you're coming from, and I feel better informed to take what you have learned and shared, and adapt and adopt it to my own situation.
Me? I use Intuit Quicken for DOS from the 1980s (fits on one floppy). It's an incredibly sophisticated relational database. I see multiple bank accounts in the same database as I see multiple wikis on one MySQL. I see transfers between bank accounts as I see shared resources in groups of wikis. I see Quicken's multiple levels of categories and classes as extremely intelligent for sorting and selecting, making reports, and changing them globally on the fly as I see ... wait a minute, media wiki's categories aren't very powerful, and there are no classes. Quicken looks ahead of my typing for anything, and suggests matches, and offers to create anything new I type without having to exit from the immediate data entry task to reconfigure anything. MediaWiki allows quick page building the same way, but scant little else. In my Quicken, backup and restore, creating new databases and new accounts, and reconfiguring the whole program are simple, I even backup to an email attachment and save it on the web, program and all. MediaWiki has none of these features for the whole program, for just your data, or even just your custom configurations. Like open source programmers, the people who designed Quicken were paid nothing at the time (one difference, though, the paper stock Quicken-designers were paid with turned out to be worth $14,000 an hour when Intuit finally went public!).
My point is that 20 years ago, many of the things I expect in any modern, sophisticated software were already well worked out and well established. And I'm not even talking about Word Perfect or Lotus 1-2-3. I'm sad that the folk in today's open source community are trying to ride two horses at once - a day job for the rent, and a night job trying to help their open source baby (or hold the reigns on what should belong to everyone). Yet, they are not standing on the shoulders of those who came before them in the arena their customers are begging them to enter. Is MediaWiki the new FORTRAN, only for programmers and support staff, or is MediaWiki the new Netscape Navigator/ Communicator/Messenger/Composer, for everyone?
I guess it's 2 cents time. Thank you for yours. That's mine.
Anybody else? Where are you coming from and going to with your MediaWiki experience?
-- Peter Blaise
=== quotable ===
Paul wrote: ... I have read many of the messages on the list of the last few weeks and resisted jumping in until I saw whether you were going to find some untapped vein of knowledge or, more likely, you would need to do a lot of the legwork yourself with hints and near answers. I do find this mailing list VERY useful but typically not because I get the exact answer I need but more usually because it sends me off in the right direction to find it myself. This is fine with me and I have learnt a ton in the last 3+ months with help from some of the regular posters here. The lack of comprehensive documentation, setup instructions or the like whilst being somewhat frustrating is something that playing with MediaWiki you have to learn to accept, for now. I really don't know anyone that has the time to devote to building the type of documentation you are looking for BUT I do suspect that if sponsorship were available there would be candidates. ... sponsorship of an open source project from ... an organization would be interesting indeed. This isn't to say that people are only motivated solely by money but they have to pay their bills which personally I find absolutely fine. I myself needed some extensive changes made to the Mediawiki UI and after spending a few days looking I realized that Mediawiki is a complete beast when it comes to the construction of the UI and it's associated CSS. I took the admittedly easy way out and simply got an expert (Jim Wilson, can't recommend him enough!) to author a custom skin (www.scribas.com/archives which does everything we need. The site is currently in stealth mode and offline but you get a feel for what it will look like. The easier parts of Mediawiki, for me, have always been the data driven components. Data is data is data and so I have been able to change pretty much whatever I want by virtue of the fact that the data is stored in a known and well documented system, MySQL. Actually, on that note we are soon to be looking to migrate the index from MySQL to Lucene for fast cross-site searching/indexing of Mediawiki and Drupal. Anyway, the reason for my post. I could be way off track here but I suspect that a lot of the, admittedly logical, requests you have generated whilst being perfectly reasonable within the black box, vendor supported world are just a little ahead of their time in the Mediawiki/open source world. Be it Drupal, Wordpress, Joomla, Mediawiki, or whatever open source project I think you will always hear gripes about the documentation and feedback in the event of bug/problem. I don't think mediawiki is any worse or better in this regard and in fact having tested three other wikis I would say it is without doubt the most solid out there. So...the solution? I don't think there is one in the short term. As much as I would love to see comprehensive documentation I wont be holding my breath. Instead, I research, ask questions and generally make progress with help from this mailing list. Ideal? No, but you pays your money and takes your choice. I could have gone to socialtext and got a fully supported wiki but the cost would have been significant. Mediawiki is 'free' but comes with a sometimes costly lack of support framework. Oh, and the reason, in my humble opinion, for the fact that you see several names for the same entity is possibly quite simple. There are hundreds of contributors, each using slightly different phraseology. Regards, Paul
[more on Scribas visual design at http://webdesign.parkertorrence.com/zfrog/portfolio/scribas/ ]
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Ever have one of those days where everything that was working, has now stopped working, and there hasn't been any change to the system ? Evidently something has changed, but you don't know what it is.
I used to have a smoothly functioning FancyCaptcha with ConfirmEdit system running just fine. Now I discover that users can no longer create accounts because the Captcha image is not being displayed. The IMG tag is generated in the create account form, but the returned image size is zero, and the IMG area disappears. When I input directly the URL for the Captcha image, e.g.: http://myhost.edu/index.php?title=Special:Captcha/image&wpCaptchaId=2350... the Wiki responds: Permission error You are not allowed to execute the action you have requested.
The IMG tag in the create account form appears as: img src="/index.php?title=Special:Captcha/image&wpCaptchaId=235016017" width="331" height="114"
But I can't figure out what permissions are being violated here ? I placed debug print statements in the FancyCaptcha.php business, and it is merrily going about its business, scanning the images directory, generating these CaptchaId's and height and width numbers from the images, and yet the page will not function. There are no extra error messages in the Apache error log.
Any hints on what to check for this situation ?
--Hiram
Problem solved. My ConfirmEdit.php and FancyCaptcha.php source were out of date and out of sync with the current version of the MediaWiki software.
I hate updates.
--Hiram
Hiram Clawson wrote:
Ever have one of those days where everything that was working, has now stopped working, and there hasn't been any change to the system ? Evidently something has changed, but you don't know what it is.
I used to have a smoothly functioning FancyCaptcha with ConfirmEdit system running just fine. Now I discover that users can no longer create accounts because the Captcha image is not being displayed. The IMG tag is generated in the create account form, but the returned image size is zero, and the IMG area disappears. When I input directly the URL for the Captcha image, e.g.: http://myhost.edu/index.php?title=Special:Captcha/image&wpCaptchaId=2350... the Wiki responds: Permission error You are not allowed to execute the action you have requested.
The IMG tag in the create account form appears as: img src="/index.php?title=Special:Captcha/image&wpCaptchaId=235016017" width="331" height="114"
But I can't figure out what permissions are being violated here ? I placed debug print statements in the FancyCaptcha.php business, and it is merrily going about its business, scanning the images directory, generating these CaptchaId's and height and width numbers from the images, and yet the page will not function. There are no extra error messages in the Apache error log.
Any hints on what to check for this situation ?
--Hiram
Good Afternoon Update Fans:
Did I miss something in the upgrade instructions that say to restart the Apache WEB server upon upgrading the MediaWiki software ?
My Captcha login problem was due to the FancyCaptcha.php being out of date with my 1.8.2 installed version. The trouble is, I upgraded to 1.8.2 last November, the Captcha login only broke down this week. I suspect an Apache reset caused the failure to happen. Perhaps Apache cache had somehow kept it running from November through May. ?
--Hiram
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hiram Clawson wrote:
Ever have one of those days where everything that was working, has now stopped working, and there hasn't been any change to the system ? Evidently something has changed, but you don't know what it is.
I used to have a smoothly functioning FancyCaptcha with ConfirmEdit system running just fine. Now I discover that users can no longer create accounts because the Captcha image is not being displayed. The IMG tag is generated in the create account form, but the returned image size is zero, and the IMG area disappears. When I input directly the URL for the Captcha image, e.g.: http://myhost.edu/index.php?title=Special:Captcha/image&wpCaptchaId=2350... the Wiki responds: Permission error You are not allowed to execute the action you have requested.
That does seem a little weird, like the permissions array somehow broke horribly.
Check if you've recently changed configs on that, or installed another extension, or upgraded something...?
- -- brion vibber (brion @ wikimedia.org)
Monahon, Peter B. wrote:
Anybody else? Where are you coming from and going to with your MediaWiki experience?
I just now started a page to document MediaWiki user interface customization. You can help write this page: http://www.mediawiki.org/wiki/Manual:Interface
MediaWiki is a Web application for running on a webserver. A highly dedicated pudding headed amateur sysadmin such as myself can install and run it on a commercial virtual web hasting account but not without considerable time on task learning how. Because I do, and in doing rely on this email list and on mediawiki.org documentation, I also contribute to this list and that documentation when I can.
MediaWiki is not easy to install and run like Quicken or Word Perfect are. MediaWiki *is* easyish to *use* as a wiki author, as a web application. In the web application paradigm the user is not the sysadmin. All the user needs is a web browser.
Thanks,
mediawiki-l@lists.wikimedia.org