Web Served 7: Wiki wiki wiki!
- Thread starter JournalBot
- Start date
I'm VERY happy to see that you're featuring MediaWiki and Etherpad. These are two fantastic tools, especially for education, in that they support collaborative "knowledge building" among students. In my opinion, knowledge building is one of the "best practice" activities that technology in the classroom enables.
Better yet, there's lots of teachers (or at least, growing numbers of teachers) who are "tech noodlers" with fledgling tech skills who will really benefit from the thorough coverage you're giving. By extension, those teachers' students will benefit too. On behalf of all of them, thanks!
Better yet, there's lots of teachers (or at least, growing numbers of teachers) who are "tech noodlers" with fledgling tech skills who will really benefit from the thorough coverage you're giving. By extension, those teachers' students will benefit too. On behalf of all of them, thanks!
Upvote
4
(4
/
0)
Oddly, when I read this, the following thought came to mind:
- "Install (or want) only what you use; use only what you need; need only what you require."
The last part may sound redundant, but it came to mind that some needs aren't really requirements. (You might "need" something because someone told you to install it, but it's not necessarily "required" for the functionality you want.) It's basically there to reinforce that fact that you should only install the bare minimum essentials you positively need/require to provide the functionality you want and actually use.
Any chance this Web Server Guide will be put into PDF or EPUB format for future reference? I'd like to stick this on my e-reader. I've been interested in learning basic web server administration and this would REALLY help in the long run.
Upvote
3
(3
/
0)
Etherpad Lite is a real-time collaborative editing app. We actually use it here at Ars occasionally for editing--an editor and a writer will sit down with Etherpad, paste in a story, and work it over while talking through it. You can see each others' edits in real-time. It works much like Google Wave used to, and in fact Etherpad Lite and Google Wave share some DNA. It's great when two or more folks want to work on a document at the same time, and it's much more real-time than Google Docs.cpengr":abnanvko said:
We're talking about it. The difficulty is in keeping things up to date. Some (or perhaps even most) of the config files and options discussed will eventually become outdated as all the different referenced applications get updated and updated and updated. It's not a problem now, but in a year or two, there'll be some noticeable drift.
Upvote
3
(3
/
0)
Setting up the AMP stack on a Windows PC can be easy and fast if you use XAMPP, and slow and painful if you don't. Personal experience, having set up several MediaWiki (as well as other wikis). XAMPP is a free download from SourceForge. It is your friend.
Upvote
1
(1
/
0)
"Wikipedia is powered by a PHP"
Should read
"Wikipedia is infected by a PHP"
PHP is crap. Popular for the same reason Win95 was popular.
Should read
"Wikipedia is infected by a PHP"
PHP is crap. Popular for the same reason Win95 was popular.
Upvote
-19
(5
/
-24)
How can something be more real time than the real time capabilities of Google docs?Pokrface":14ypxklw said:
Upvote
1
(1
/
0)
Faster? Or doesn't require a 'send' command to reveal typed text? Haven't used GDocs bar storage let alone collaboratively so just guessing.
Upvote
0
(0
/
0)
We're talking about it. The difficulty is in keeping things up to date. Some (or perhaps even most) of the config files and options discussed will eventually become outdated as all the different referenced applications get updated and updated and updated. It's not a problem now, but in a year or two, there'll be some noticeable drift.[/quote]
Hmm... There is that. You could just due it the way textbooks and other guides do it - Title Here: 20xx Edition - or some such. On the other hand, I'm not sure if you would care to maintain an in-depth beginner's guide like this long-term. IT development of any type is a relative fast-paced industry (especially with the current quick development cycles and updates many projects have adopted.)
How relevant do you wish to keep this series for the future? I wouldn't mind getting a current PDF/EPUB version now and then grabbing an updated version as needed however many months down the line later. (For sure, you can't really afford a monthly refresh like Chrome or FF ;-)
Upvote
0
(0
/
0)
Dokuwiki (https://www.dokuwiki.org/dokuwiki) doesn't require a database engine and is easier to install. It is on par with MediaWiki feature wise. The advantage of MediaWiki is the better performance for a large number of users but it doesn't make any difference with less than 100 users.
Upvote
2
(3
/
-1)
Bengie25":3k2qlg8n said:
I'll bite. Any reason to back up your statement, or should I add you to my ban list for being a troll? Win95 was popular, as I understand it, for being an operating system that was (fairly) compatible with market-leader Win3.1 AND it ran market leader Microsoft Office. PHP's reason for being popular are not, as I understand it, related at all.
Upvote
2
(5
/
-3)
Upvote
1
(1
/
0)
Pokrface":1bytv39p said:
I'll point out that configuration drift will occur regardless of distribution mechanism. If the people want to read the series as an ebook, you should consider doing it. Are you really going to come back and regularly update these "live" articles?
Upvote
0
(1
/
-1)
I'd like to see something about setting up a mail server too, since it was mentioned at the end of the article, though the article does also say its too in depth. If there is too much to it, could someone recommend some good open source/free email servers I could mess with and try to get working? I have looked myself but its hard to see which are well thought of/active/stable/supported in the time I have to research it.
Also, since education was mentioned, I'd love to see an article about getting Moodle working on this setup. I don't know if its possible (its definitely aimed at Apache) and it might be a bit niche, but if you have the time...
I've really enjoyed these so far, can't wait for the next one.
Upvote
0
(0
/
0)
koolraap":3sqfu5r6 said:
In the past PHP had some really badly built features, and to maintain backwards compatibility a lot of them still exist and are just labelled as deprecated on php.net (For example mysql_escape_string, which was replaced by real_mysql_escape_string, but both still exist). It also didn't introduce object orientated code until version 3.0 and namespacing until version 5.0. Lastly, the low barrier for entry makes for a lot of people who aren't familiar with good coding practices being able to get jobs in the industry and build things which work but are a real nightmare to maintain for anyone else working on them
It's improved a lot over the last few years, but it does still have issue with security and bloat (being a scripting language it's difficult to get around this). As a language though it's probably on par with other equivilent languages, it's more the developers working with it who cause problems. Or possibly Bengie is just a Python/Ruby fanboy who likes bitching about how inferior PHP is, that's not uncommon either
Upvote
4
(4
/
0)
Near-instant refresh, very little lag (obviously bound by the latency of your connections). Etherpad lite is pretty darn close to actual-for-real instant realtime. Plus, changes are automatically annotated and tracked and can be played back and forth. It'd be correct to say that google docs is a text editor with the capability to do real-time document collaboration, whereas EPL is a real-time document collaboration tool. One can do it, the other is built for it.Thinine":3cygy1i1 said:
I mention DokuWiki in the article as an alternative. I used DokuWiki for about six months and though I liked it, in the end I switched to MediaWiki because I found my users demanding MediaWiki-like functionality that DokuWiki couldn't provide, particularly with respect to laying out images. I worked with DokuWiki plugins and tried to approximate, but in the end I gave up and installed MediaWiki.agrouf":3cygy1i1 said:
Honestly, DokuWiki could outperform MediaWiki in a single-server setup any day of the week, because it can take advantage of whole static objects being stored in a fast file system cache.
A few months ago, I would have said to simply use the free version of Google Apps...but that's dead now. The tool to use would be either postfix or something like the free version of Zimbra, but mail from home isn't always a good idea because many mail servers blacklist residential IP blocks to protect themselves from spam zombies. Additionally, a lot of ISPs block outbound SMTP traffic. And postfix isn't the friendliest thing to set up.Muzos":3cygy1i1 said:
In short, probably not, but there are tutorials out there that aren't awful.
Potentially--the series is proving popular enough that it might be a good use of time to sweep through every 6 months or so and ensure the procedures are valid. I do at least have the option that way. Plus, creating an ebook isn't a zero-work proposition--I can't just snap fingers and it's done. We are indeed considering it, though, as I mentioned. Ultimately, that decision is up to Nate and Ken.undervillain":3cygy1i1 said:
I've addressed this sufficiently in the past six articles' comments.Bengie25":3cygy1i1 said:
Upvote
4
(4
/
0)
Bengie25":3eusqfc2 said:
You've been downvoted, but it is true. So, so true. Most people are not aware of the depth of PHP's badness. Probably the best article on PHP's awful nature is PHP: a fractal of bad design. It's hard to believe how much poorly implemented and broken crap they've managed to jam into the language and its libraries.
Upvote
-5
(1
/
-6)
We use it for coding interviews. This is particularly useful and cost-effective for weeding out people that we would otherwise have had to fly in.cpengr":2znqkw4p said:
We still fly people in if they pass the Etherpad test.
Upvote
1
(1
/
0)
These articles exist as PDFs for premier subscribers.undervillain":3rswiwuu said:
Upvote
0
(0
/
0)
The idiot was downvoted because he's a content-free troll.Gracana":3poadbzk said:
At any rate, not using something because you don't like the language it's written in is a shitty reason to not use something.
Upvote
6
(6
/
0)
Since we have memcached installed already why wasn't it used as the object cache for the wiki? Just wondering....
Upvote
0
(0
/
0)
Upvote
0
(0
/
0)
I'd just like to underscore how important it is to implement some kind of user account limitations to your wiki (and I'm glad the article covered it)-- The amount and tenacity of signup/edit bots is truly mind-boggling and will make your life miserable if you let them.
I have an obscure, small-traffic mediawiki and that used to get hit all day, erryday. But since I don't expect to get new users without knowing about it, going President of Madagascar and shutting down signups solved that.
I have an obscure, small-traffic mediawiki and that used to get hit all day, erryday. But since I don't expect to get new users without knowing about it, going President of Madagascar and shutting down signups solved that.
Upvote
0
(0
/
0)
That is an excellent question. The answer is two-fold: first, because using APC requires less configuration and is easier to implement. Second, not using memcache opens the possibility of using Varnish cache later, which I'll touch on in the closing piece. The config file spot used to specify memcache is the same one used to specify Varnish or another external cache.kperrier":er9nmkqr said:
However, absolutely nothing is stopping you from using memcache if you'd like--go for it!
Upvote
0
(0
/
0)
Lee, I love the ever loving shit out of this series. Keep up the excellent work!
Upvote
2
(2
/
0)
...
Doesn't the first regex match files ending with both ".php5" and ".php" (that's what the question mark is for)? Why also the second (which matches ".php" and ".ph")?
Upvote
0
(0
/
0)
I'm enjoying these "build your server" features as well, however, these features (especially this one), seems to forget a major item...backing up the data generated by the apps.
To me, this would be the worst possible scenario. You deploy an awesome wiki, lots of people use it, then something happens, and all the data is lost.
I hope that you do a "Backing Your Data Up" item, too!
To me, this would be the worst possible scenario. You deploy an awesome wiki, lots of people use it, then something happens, and all the data is lost.
I hope that you do a "Backing Your Data Up" item, too!
Upvote
1
(1
/
0)
Here are some spam account measures that have worked well for me with my hematology/oncology wiki:
-restrict editing rights of regular users as you suggest (unless one has a high volume self-policing wiki and really wants as many users as possible
-For bots that use variations of the same username for the spam accounts (e.g. Podpole*, Puwok*), https://www.mediawiki.org/wiki/Extensio ... _Blacklist can be helpful
-Install "Kitten auth": http://www.mediawiki.org/wiki/Extension:Asirra. It asks users to pick only pictures of cats out of thumbnails of either cats and dogs. This has been hugely effective and has stopped almost all spam account creation. I did this because I didn't like spam account creation flooding out legitimate entries in the recent changes log.
-restrict editing rights of regular users as you suggest (unless one has a high volume self-policing wiki and really wants as many users as possible
-For bots that use variations of the same username for the spam accounts (e.g. Podpole*, Puwok*), https://www.mediawiki.org/wiki/Extensio ... _Blacklist can be helpful
-Install "Kitten auth": http://www.mediawiki.org/wiki/Extension:Asirra. It asks users to pick only pictures of cats out of thumbnails of either cats and dogs. This has been hugely effective and has stopped almost all spam account creation. I did this because I didn't like spam account creation flooding out legitimate entries in the recent changes log.
Upvote
1
(1
/
0)
Nope, memcached takes the place of APC (via $wgMainCacheType) although it doesn't cache opcodes like APC. On the other hand, you can chose Varnish instead of Squid (via $wgUseSquid), as it's more specifically designed as a proxy cache server and easier to set up than Squid.Pokrface":1t3t0eg7 said:
As far as which configuration to chose, MediaWiki recommends using APC on single-server setups and memcached where you can set it up on a separate, more dedicated server.
Anyway, I'd like to add to this. I run a fairly busy multilanguage MediaWiki site (~6-8GB/day of bandwidth). We've found using nginx instead of Apache to be a huge performance boost, to the point of Apache not even functioning under the same load nginx breezes through without issues. Also we've set up Scribunto to do some pretty crazy Lua-based template programming not otherwise available in MediaWiki markup. Finally, to control spam account creation, we used QuestyCaptcha from ConfirmEdit to do text Q/As at account registration, since image-based Captchas are pretty much useless now. It's completely stopped spam account registrations, for the most part.
Upvote
0
(0
/
0)
It'd still be great if you guys could have them all in one central location that was available easily! I appreciate the thought towards keeping things up to date though.
Upvote
0
(0
/
0)
I'll echo that I've seen lots of people have good experiences with QuestyCaptcha. I think it is particularly good if the users of a site would all be expected to know a specialized question. For example, a Simpson's site might ask: "What's the name of Homer's son?"Pokrface":14ixz6vo said:
Momiji: You have a forum PM.
Upvote
0
(0
/
0)
As an aside, although I found Wikimedia surprisingly easy to setup when I tried it a few years ago, for many tasks it's hitting a cockroach with a bazooka.
For a quick and easy wiki experience, I find TiddlyWiki (especially in combination with Tiddlyspot) to a much more useful application.
For a quick and easy wiki experience, I find TiddlyWiki (especially in combination with Tiddlyspot) to a much more useful application.
Upvote
0
(0
/
0)
imgx64":379r9u62 said:
Yeah, I noticed this, too. The second block's redundant as a result.
Upvote
0
(0
/
0)
Lee,
My wiki.conf file appears to be causing the following error when I try to reload nginx:
"Reloading nginx configuration: nginx: [emerg] location "/wiki/" is outside location "\.php$" in /etc/nginx/site-configs/wiki.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed"
I edit my www and wiki.conf files mostly by copy/paste so I would be really surprised if it was a typo, but after some time researching it online, and with my limited time using nginx I'm still at a loss.
Again, this series is quite a treat. Regards,
Angelo C.
My wiki.conf file appears to be causing the following error when I try to reload nginx:
"Reloading nginx configuration: nginx: [emerg] location "/wiki/" is outside location "\.php$" in /etc/nginx/site-configs/wiki.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed"
I edit my www and wiki.conf files mostly by copy/paste so I would be really surprised if it was a typo, but after some time researching it online, and with my limited time using nginx I'm still at a loss.
Again, this series is quite a treat. Regards,
Angelo C.
Upvote
0
(0
/
0)
Angelo, can you paste your full nginx site config (as a Code block), please? It'll help diagnose where the problem is.
Upvote
0
(0
/
0)
- Status