Running Weblogs with Slash

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter is a whirlwind tour of Slash. It begins with a short history of Slash, then explores a typical site through the eyes of an average user. It explains the life cycle of a Slash Story, from user submission to published glory, and ends with a skeletal view of the underlying software. Subsequent chapters put meat on these bones. This chapter draws the broad outlines of the map and the major thoroughfares.

The Slash Story begins with Slashdot, one of the most successful news and technology sites on the web. Slashdot's motto says it all: "News for nerds. Stuff that matters." Back in 1997, Rob "CmdrTaco" Malda started a website known as Chips & Dips, served from his student account at Hope College in Michigan. That summer, Malda spent his time writing and updating static HTML files. Every few days, he'd start a new page. Computer programmers like to talk about scalability, the idea that a resource can keep up with increasing demands. Editing HTML by hand is time-consuming and tedious, and quickly scales beyond the attention span of a typical programmer. Computers are fully capable of handling these mundanities.

The site grew in popularity. Malda and his friend Jeff "Hemos" Bates registered the slashdot.org domain and moved to a dedicated machine in October 1997. They took the opportunity to automate parts of the publishing process. Malda started learning Perl and enlisted the help of other friends (Patrick Galbraith, Cliff Wood, Jaime McCarthy, and Jonathan Pater) to add templates and a web interface for editing Stories. Soon, they were adding features like madmen—the distinctive visual look of the site, user polls, remote administration, and user comments.

The site became a place to test new ideas, and the coders had to learn to cope with a perpetually growing userbase. Malda discovered mod_perl and MySQL, and by April 1998, had ported the software for extra speed and features. His self-confessed first (significant) Perl program grew into a powerful tool for running Slashdot. Somehow, the site put up with a traffic load that could often choke other servers, occasionally eating the entire bandwidth allotment for the city of Holland, Michigan.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Slash Story begins with Slashdot, one of the most successful news and technology sites on the web. Slashdot's motto says it all: "News for nerds. Stuff that matters." Back in 1997, Rob "CmdrTaco" Malda started a website known as Chips & Dips, served from his student account at Hope College in Michigan. That summer, Malda spent his time writing and updating static HTML files. Every few days, he'd start a new page. Computer programmers like to talk about scalability, the idea that a resource can keep up with increasing demands. Editing HTML by hand is time-consuming and tedious, and quickly scales beyond the attention span of a typical programmer. Computers are fully capable of handling these mundanities.

The site grew in popularity. Malda and his friend Jeff "Hemos" Bates registered the slashdot.org domain and moved to a dedicated machine in October 1997. They took the opportunity to automate parts of the publishing process. Malda started learning Perl and enlisted the help of other friends (Patrick Galbraith, Cliff Wood, Jaime McCarthy, and Jonathan Pater) to add templates and a web interface for editing Stories. Soon, they were adding features like madmen—the distinctive visual look of the site, user polls, remote administration, and user comments.

The site became a place to test new ideas, and the coders had to learn to cope with a perpetually growing userbase. Malda discovered mod_perl and MySQL, and by April 1998, had ported the software for extra speed and features. His self-confessed first (significant) Perl program grew into a powerful tool for running Slashdot. Somehow, the site put up with a traffic load that could often choke other servers, occasionally eating the entire bandwidth allotment for the city of Holland, Michigan.

These humble beginnings were nothing new, either on the personal or technological levels. Many Horatio Alger stories have come from the heady Internet days of the late 1990s. Some remain. Many modern websites have gone through a similar evolution, from static pages to templates, flat files to database-driven content management systems. Slashdot was different in two important ways.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The ideal place to start is to explore an existing Slash site. It will demonstrate the current possibilities, perhaps inspiring fresh ideas. There's no shame in imitating a successful site, either. Imitation is the sincerest form of flattery, and sincere flattery is usually good currency for the technical crowds. Being a user on another site gives a unique perspective. How does the site work? Who does it attract? How has its focus changed over time? How does it handle conflict and growth? You will probably also come up with a list of things you'd handle differently. They may be philosophical, or they may be as simple as a different color scheme or as complicated as a new moderation system.

Most users don't get to see the seamy underbelly of Slash. Site administrators spend most of their time working with a special interface. The underlying metaphor of Stories comes into play. The essential mechanisms are exposed as pulleys and trapdoors. Slash has a staggering wealth of editorial tools, but just knowing what's available returns things to manageable levels.

With theories and introductions out of the way, it's time to install the beast. All of this power comes at a price--someone has to understand the underlying components well enough to put them together. The Slash team has spent a tremendous amount of time smoothing things out. Gone are the days of reading Malda's mind. With a little Unix experience, a handy installation guide, maybe some junk food to bribe your local teenaged hacker, Slash will be up and running.

Of course, the default installation produces a rather generic site, looking just like unconfigured Slashcode and behaving much like Slashdot does. Site customization will fill the days of the site administrators. The first order of business is to recruit other people to ease the administrative burden. The second is to fill in some of the blanks. Slash has dozens of configuration options, and it's easy to control everything from presentation to algorithmic behavior.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The original and most popular Slash site is Slashdot, and most users first encounter Slash there. The site's homepage looks something like Figure 1-1. (The default appearance of a newly installed Slash site is slightly different.) The most important page feature is the central column, which lists Stories in reverse chronological order. Each Story is introduced in a separate box. This introduction may, in fact, be the entire Story. The box also provides other information, including the Story's title, date, and time of publication; the number of comments made on the Story so far; and the person responsible for the Story.

Figure 1-1: The Slashdot homepage

Other navigational aids surround the Story column: links to site features, live headlines pulled from other sites, a Search form, a multiple-choice user poll, and a list of older Stories that have been pushed off the homepage by newer ones.

The ReadMore... link in any Story box leads to that Story's individual page. This displays the full Story along with user comments. Story content may be limited to the "Intro" text (displayed on the homepage), or it may include "Extended" text (displayed only on the Story page). An HTML form beneath the content allows you to add a comment or to change the presentation of existing comments.

Comments may be viewed in threaded, nested, or flat formats, or may be suppressed entirely. They may also be sorted by the date and time of posting or by their moderation score (an aggregate value of other users' opinions of the comment). Users can also suppress the display of comments with scores below a certain threshold value. Chapter 6 describes the comment and moderation system in full detail.

Slash allows users to create their own accounts, which can be used to store site customizations. Each registered user will have a unique

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As mentioned earlier, each Slash site has a set of privileged users, called Authors (or Editors), charged with the responsibility of approving and publishing Stories. Some Authors may have additional privileges such as modifying the site's appearance, deleting user comments, adding or deleting Slashboxes, or regulating the privileges of other Authors.

The phrase Slash site administrator can be a little misleading. There is no special "Administrator" entity in the software, merely Authors of varying levels of privileges. "Slash site administrator" is shorthand for "any of the site's Authors who has sufficient privileges" for the operation under discussion.

Authors are simply regular users with additional access bestowed by an existing Author with the ability to do so. Thereafter, these users have access to the Author interface (at the relative URL admin.pl), which provides access to site administration functions. Depending on their access level, Authors have an additional row of links to administrative options at the top of the page. The Author interface uses a simpler layout with a grayed-out color scheme to distinguish it from regular pages (see Figure 4-1). Furthermore, a logged-in Author sees special interface elements on every page of the site that do not appear for run-of-the-mill users, such as the Author menu, a row of HTML links to the various pages of the Author interface. The links available in the Author menu vary depending on the privileges of the Author viewing it. For example, only Authors with the highest possible privilege level will see the Authors or Vars links.

The homepage of the Author interface is the Stories list, available via admin.pl or through the Stories link in the Admin menu. The Stories list provides Authors with a quick overview of recent publishing activity on the site. The New link allows an Author to create a new Story from scratch. The nSubmissions link leads to the Story queue, where users have submitted n articles. This is the most important source of new content for many Slash sites. Chapter 4 describes the mechanisms of the Slash publishing cycle in detail. The next section presents a broad overview of the publishing cycle.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Like living organisms, political movements, and dot-com startups, Slash Stories have a well-defined life cycle (see Figure 1-11). They are born (usually as user submissions), they mature (when published by an Author), they live productively for a while (as users add comments and moderate those comments), and, after a full life, they go to heaven (are archived, where no more comments can be added).

Figure 1-11: The life cycle of a Slash Story and comments

Most Slash sites operate somewhat like community newspapers. The people in a small town have a number of shared concerns that arise from living in the same legal jurisdiction, in the same school district, and so on. A small-town newspaper serves as both a mirror held up to that community and a speakers' platform for the people to conduct public business and make their voices heard. Readers can write letters to the editor or opinion essays for the editorial page, or just call the attention of the newspaper staff to issues they feel deserve coverage. In the case of a Slash site, the common unifying factor of its audience is less likely to be geographic proximity than a social or technical topic of common interest, but Slash sites (and other kinds of public weblogs) provide the same mechanisms of reportage and discussion that a good small-town newspaper provides for its community.

A Story usually starts off as a user submission. Each Slash page has a SubmitStory link where anyone, even Anonymous Users, can suggest a story to the site Authors. This can be as simple as a URL to something interesting elsewhere on the web or as complex as a 4,000-word essay in plain text or jazzy HTML. Submitted stories live in a database table. Site Authors view this queue of submissions, choosing which stories to publish. Slash can be configured to allow the public to view the submission queue. Normally only the Authors can see it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In Version 2.0, Slash underwent a complete architectural overhaul. The new Slash provides features such as themes, database abstraction support, an API for the database, use of the Perl Template Toolkit, an improved and streamlined installation process, hooks to support addition of third-party modules, and better support for hosting multiple Slash sites.

Slash has always been Free Software, available under the GNU General Public License. With the open-sourcing of the MySQL database, all of Slash's underlying infrastructure is now open source as well. Slash is built on the Apache web server, the mod_perl Apache module, and a relational database that speaks Structured Query Language (SQL). (MySQL is supported out of the box. Some work has been done to port things to the excellent PostgreSQL database, though it lags behind. Oracle has some preliminary support.)

At the bottom of the traditional software architecture "layer-cake" diagram (see Figure 1-12) squats the operating system. Slash was born on Linux and has been run successfully on FreeBSD, OpenBSD, and several commercial flavors of Unix, including Solaris and HP-UX. As of this writing, Mark Breitenbach (geo@other.org) has ported Slash 1.x to NT; track the progress of the port at http://geo.trippy.org/nt-slashcode/.

Figure 1-12: Diagram of Slash software infrastructure and architecture

The web server and database server sit on top of the operating system. Slash requires Apache, the world's most widely used web server, compiled with the mod_perl module, which adds a Perl virtual machine running inside the Apache process. This enables Perl applications such as Slash to run as persistent "applets" instead of forked-off children using the Common Gateway Interface (CGI). When Apache starts, it compiles and loads these applets, initializing them (including retrieving configuration data). They remain in memory to handle client requests. This spends more memory on Apache child processes but improves performance by avoiding the delays of loading, compiling, and initializing a separate CGI process for each client request.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Installing Slash is not difficult, but there are multiple steps and several possible complications. This chapter describes the complete process, from downloading Slash and all of its requirements through compilation and installation. Please note that this chapter does not cover everything there is to know about configuring and using these tools. It does walk through the basic steps to get a Slash server up and running.

The Slash install process improved greatly for the 2.0 release. The latest distribution includes a GNU makefile, plus a Perl script (install-slashsite) for customizing the installed Slash server with site-specific information, such as the machine's fully qualified domain name (FQDN) and the name of the local Slash user. These should work on any free Unix system; however, they are guaranteed only on GNU/Linux systems. ("Linux" is used as a convenient shorthand for "an operating system containing tools from the GNU project, built around the kernel named Linux".)

Because this chapter can't reasonably go all the way back to the Big Bang, it assumes certain things. You should already have a working and compatible Unix-like operating system. As with most Unix software, you will need root access, along with at least some basic system administration experience. If you're new at this, read the instructions completely before beginning an installation, then follow along.

In addition, prepare the following information:

The installed location of the Slash files, also known as the Slash home directory. The default, /usr/local/slash/, is highly recommended. Subsequent examples assume this to be the case. If you use another location, modify them accordingly. Earlier versions of Slash installed into /home/slash/ instead.
The Slash system account name. By default, this is slash. This user will own all files and directories associated with Slash. Machines running multiple Slash sites should have a different system user for each site.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Because this chapter can't reasonably go all the way back to the Big Bang, it assumes certain things. You should already have a working and compatible Unix-like operating system. As with most Unix software, you will need root access, along with at least some basic system administration experience. If you're new at this, read the instructions completely before beginning an installation, then follow along.

In addition, prepare the following information:

The installed location of the Slash files, also known as the Slash home directory. The default, /usr/local/slash/, is highly recommended. Subsequent examples assume this to be the case. If you use another location, modify them accordingly. Earlier versions of Slash installed into /home/slash/ instead.
The Slash system account name. By default, this is slash. This user will own all files and directories associated with Slash. Machines running multiple Slash sites should have a different system user for each site.
The fully qualified domain name of the server. This is the machine name that will appear after http:// in URLs pointing to the site. For example, Slashdot's FQDN is (more or less) slashdot.org. It must be a valid DNS name for the network on which the site will serve requests.
The directory containing source code for the installed components. The examples to follow assume that the directory is /usr/local/src/, with a named subdirectory for each different software package. (For example, Slash would be in /usr/local/src/slash-2.2.0/, Apache in /usr/local/src/apache-1.3.22/, and so forth.)

Slash is a complex piece of software, depending on several other complicated pieces of software. Most of the questions from new users come during the installation phase. You are expected to read this chapter before installing Slash. You are expected to read the installation instructions that come with Slash before attempting to install it. The same very helpful people who might be willing to help you with a hirsute problem have already provided many answers to common problems. Do yourself a favor and ask good questions (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The starting place for all things Slash is http://slashcode.com/, the Slashcode web site. Slash-based, naturally, it serves as a community newspaper for Slash site administrators and operators, and is the definitive source of the most up-to-date information about installing and maintaining Slash. After your site is up and running, submit a "YASS" (Yet Another Slash Site) announcement for free advertising. For now, simply locate and download the latest stable release.

The current stable release of Slash is always available for download from SourceForge. This is a free service for open source projects, funded by Slashdot's parent organization. The Slash developers use SourceForge for development mailing lists, bug tracking, and download services. The Slash project page on SourceForge is at http://sourceforge.net/projects/slashcode/. (Slashcode's Quick Links Slashbox has a convenient link to this page.) Scroll down to "Latest File Releases" and choose the Download link for "slashcode". ("Slashcode-dev" is the latest development version for the next release and may not be stable enough for regular use.) As of this writing, the current stable release is Slash 2.2.3, with a development release of 2.3.0.

The most recent version of Slash will appear at the top, with older versions following in reverse order. The version numbers in the "Release & Notes" column are links to the README file for each release. The filenames, of the form slash- VERSION .tar.gz, are links to the actual distribution files themselves. Save the appropriate file to the source directory.

Source distribution files with the .tar.gz extension are called tarballs. They are created by first archiving source directories with the Unix tar utility, then compressing them with the GNU gzip utility. To unpack a tarball:

# cd /usr/local/src

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The basic steps for installing Slash and its components are:

Prepare the ground. Create system users, make home directories for software, and set file and directory permissions appropriately.
Prepare the database. Install the database software, create a database user account for the site, and create and populate the basic Slash tables. The distribution includes canned SQL scripts to make this easy. This chapter assumes you're using a MySQL database. Other software will be similar, but please refer to its documentation and the current version of INSTALL for any known caveats.
Install Perl, Apache, and mod_perl . Although many Unix-like operating systems come with Perl already installed, building Apache with mod_perl requires the Perl source.
Install the Perl modules that Slash requires. This is also easy, thanks to Andreas König and his marvelous CPAN module, which can find and install Perl modules. (The CPAN, or Comprehensive Perl Archive Network, is a repository of reusable Perl components.) Slash includes a CPAN Bundle file, which lists the modules to be installed.
Make and install Slash. Thanks to the makefile provided with recent Slash releases, this part is so easy a typing poodle could do it. (Be sure to get video if this actually happens.)
Run install-slashsite to configure each individual Slash site on a machine. This Perl script asks for the server name and the name of the virtual database user. It automagically updates the Apache configuration file and Slash configuration variables as needed. The install-slashsite script also installs any optional Slash modules.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As mentioned previously, most of the installation steps require root access. For users without prior administrative experience, this can be a daunting task. The O'Reilly and Associates guides UNIX in a Nutshell and Running Linux are both good Unix references.

The first step is to create a unique Unix user account, not associated with a human user. Running server daemons such as Apache or slashd as root is a serious security risk. The system user will own all files associated with Slash, and the Slash daemons will run as if this user had executed them. Most Unix systems provide a nobody account for this purpose. Another good option is to create a new user named slash. The more services running as nobody, the more damage an attacker can do if he gains access to the account.

The slash user needs to belong to a group as well. This is convenient and practical. Any other user with membership in the slash group can work with Slash files and directories that allow group access. The easiest way to create a new group is with the groupadd command, provided by some operating systems (it handles details such as choosing the next available group number automagically):

# groupadd slash

If this command is not available, manually edit the /etc/group file. Add a line defining the slash group. On the nanodot.org machine, this line is:

slash:x:501:dkrieger

This means that the user named dkrieger is in the slash group. The group number is 501, the lowest unused number above 500. (On many Linux machines, group and user numbers below 500 are reserved for special system groups and users. This can vary between operating systems.)

Next, create the slash user. Most Linux systems provide the helpful useradd command:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The simplest Slash installation features one site running on one web server. This is not a limitation of the software. Thanks to advanced features of Apache and the Perl DBI modules, as well as clever coding, Slash can be used to run several smaller sites on one machine (in a managed hosting situation, perhaps), as well as one large site served by several machines. It's even possible to mix the two configurations.

Because it was designed to run Slashdot, the Slash software is scalable from a single machine to large web site clusters. Based on the level of traffic you expect, you can choose from several possible server configurations. Most new sites start with low requirements and can live comfortably on a single, properly tuned machine. Figure 2-2 shows other available options. Putting the database on a separate machine, connected via a high-speed network, will alleviate some processing and memory crunch.

Figure 2-2: Several possible Slash configurations, scaling with the expected web traffic

Larger sites might run several web servers with a single database. In this case, the individual servers would mount an NFS directory served by one machine (which may or may not itself be a web server), and access a database on another machine. This is the configuration Slashdot itself uses. For extremely high traffic sites, it's possible to use database replication to reduce the backend bottleneck. If your site is this successful, buy several copies of this book.

Heavy-traffic sites can get a speed boost by serving images and static content from a separate web server. This allows a small and fast server to cache and dole out unchanging information as quickly as possible, reserving the heavy-but-powerful mod_perl and Slash processes for dynamic content. Be sure to modify the imagedir Slash configuration variable to point to the root URL for the image server. Most of the other standard performance improvement suggestions also apply.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

While site users only see the front end of Slash, administrators and Authors have a special interface called backSlash, which controls everything from posting Stories to managing Authors. The first order of business on any new site is to create new Author accounts and modify the default configuration to fit the site's true goals. This chapter describes the web interface for managing Authors and variables. Subsequent chapters describe the rest of the Slash administrative interface, but the following functions provide the most basic level of control over the operation of the server.

Any logged-in Author will see a special row of links below the main title banner on any page. This is the Admin menu. If the heart of Slash administration is the backSlash interface, its nerve center is the Admin menu. It holds the keys to unlock the remote administration features provided by the admin.pl applet.

A Slash Author account is simply a user account that has been granted additional privileges. Versions of Slash before Release 2.0 had separate accounts, in which an Author had to log on first as a user and then as an Author. Current versions of the software removed this distinction, turning Authorship into a user attribute. This is much more convenient.

Each user account within Slash has an assigned security level or seclev. This is an integer between 0 and 10,000. Regular users start with a seclev of 1, and the Anonymous User has a seclev of 0. Authors must have a seclev of at least 100. In addition, a special Author flag is set on their accounts. In a fresh Slash installation, there is only one Author. The administrative account created during the site installation stage will have a user ID of 2 and a seclev of 10,000.

Think of a 10,000-point seclev as the root account on a Unix machine. Its wielder is allowed to do powerful things because he is not prevented from doing stupid things. Consequently, the initial administrative account has full access to every function of the web interface, including promoting and demoting other Authors and modifying site configuration variables. A seclev can exceed 10,000, but this bestows no additional privileges. You're either omnipotent or you're not.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Any logged-in Author will see a special row of links below the main title banner on any page. This is the Admin menu. If the heart of Slash administration is the backSlash interface, its nerve center is the Admin menu. It holds the keys to unlock the remote administration features provided by the admin.pl applet.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A Slash Author account is simply a user account that has been granted additional privileges. Versions of Slash before Release 2.0 had separate accounts, in which an Author had to log on first as a user and then as an Author. Current versions of the software removed this distinction, turning Authorship into a user attribute. This is much more convenient.

Each user account within Slash has an assigned security level or seclev. This is an integer between 0 and 10,000. Regular users start with a seclev of 1, and the Anonymous User has a seclev of 0. Authors must have a seclev of at least 100. In addition, a special Author flag is set on their accounts. In a fresh Slash installation, there is only one Author. The administrative account created during the site installation stage will have a user ID of 2 and a seclev of 10,000.

Think of a 10,000-point seclev as the root account on a Unix machine. Its wielder is allowed to do powerful things because he is not prevented from doing stupid things. Consequently, the initial administrative account has full access to every function of the web interface, including promoting and demoting other Authors and modifying site configuration variables. A seclev can exceed 10,000, but this bestows no additional privileges. You're either omnipotent or you're not.

Only the most trusted Authors should be allotted this power. In particular, Authors at seclev 10,000 can change their security levels—and those of other Authors. Be very cautious. Any Author with this power can easily and quickly seize the reins of power (such as they are), demoting all other Authors. It is advisable to restrict this power to those who will use it wisely and benevolently, like famous Slash gurus. Section 8.5 in Chapter 8 has other advice on selecting and cultivating Authors.

Also, if you accidentally reduce the initial account's seclev before creating any other Authors with this power, you will have to modify the users table in the database to recover from your mistake.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Configuration variables control important aspects of the site's behavior. For example, the allow_anonymous variable controls whether anonymous users can post comments. Earlier versions of Slash stored these variables in a special file. They moved into the database with Version 2.0, and the Slashteam added a browser-based interface. The Vars link in the Admin menu leads to the Variables interface (see Figure 3-3).

Figure 3-3: The Variables interface, used to edit configuration variables

All of the available variables are listed in the Select Variable Name menu. To edit or to view a specific variable, select its name from the menu and click the Select Var button. The other form fields will be filled in when the page refreshes. The Variable Name and Value boxes behave almost as expected. If you change the value and click Save, the database will be updated with the new value. If you type a new name in the Name box, a new variable will be created. If you select an existing variable and change its name, a new variable will be created, and the old variable will maintain its current value. New values will take effect within the system when Apache is restarted.

The Description field has no effect on site or variable behavior. It is simply descriptive and can be edited at any time. In case of emergency or forgetfulness, it's best to keep the descriptions up-to-date.

Slash stores all configuration data in the database as text and relies on Perl to convert values to numbers or boolean values when appropriate. Variables that have yes-or-no effects, such as allow_anonymous, are treated as booleans. In Perl, anything that evaluates to 0 or the empty string ("") is considered "false". Everything else is considered "true", including the strings true and false. To avoid ambiguity, the default variables use the numbers 1 and 0 to indicate true and false, respectively.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

No matter what Topics a weblog covers, it will always require fresh content. In Slash terms, these are Stories. Consequently, most Authors will spend their time in the Stories list. It is always available from Stories or the relative URI /admin.pl. Authors can review submissions, edit published Stories, and even create new Stories (see the New link in the Admin menu).

The Stories list (Figure 4-1) is the default page of the Admin menu. It's like a big map in the war room, used to review and coordinate the current site activity. As you'd expect, it is full of data. Most of the activity is centered around reading or editing Stories; an Author may decide to fix a typo in a Story title or introduction, or the administrator might decide to browse a Story that's attracted an unusual number of comments or page reads.

Figure 4-1: The Stories list (Stories set to Never Display are highlighted)

Stories appear on the list in reverse chronological order--newest first, grouped by day of publication. The horizontal columns on the page are unlabeled, but they are relatively straightforward. The leftmost column holds the Story number, with no special meaning outside of the Stories list. The number is a link to the Edit Story page, used to update a Story. The Story title is a link to the normal Story display page, as seen by users. The next three columns show the credited Author, the Story Topic, and the Story Section, respectively. Only the Section is linked, and it leads to the Section homepage.

The next two columns are numeric. The first is the number of page views, and the second is the current number of posted comments, if any. The number of views should exceed the number of comments because users must normally view the page before posting a comment. Not every reader will feel the need to comment, though Stories comparing operating systems or starship captains may lead you to believe otherwise.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Stories list (Figure 4-1) is the default page of the Admin menu. It's like a big map in the war room, used to review and coordinate the current site activity. As you'd expect, it is full of data. Most of the activity is centered around reading or editing Stories; an Author may decide to fix a typo in a Story title or introduction, or the administrator might decide to browse a Story that's attracted an unusual number of comments or page reads.

Figure 4-1: The Stories list (Stories set to Never Display are highlighted)

Stories appear on the list in reverse chronological order--newest first, grouped by day of publication. The horizontal columns on the page are unlabeled, but they are relatively straightforward. The leftmost column holds the Story number, with no special meaning outside of the Stories list. The number is a link to the Edit Story page, used to update a Story. The Story title is a link to the normal Story display page, as seen by users. The next three columns show the credited Author, the Story Topic, and the Story Section, respectively. Only the Section is linked, and it leads to the Section homepage.

The next two columns are numeric. The first is the number of page views, and the second is the current number of posted comments, if any. The number of views should exceed the number of comments because users must normally view the page before posting a comment. Not every reader will feel the need to comment, though Stories comparing operating systems or starship captains may lead you to believe otherwise.

The final column shows the official Story posting time. This, like the Author field, can be misleading. The time does not necessarily reflect the point at which the Story was accepted, nor does it take into account the possibility that another Author has edited the Story. It simply lists the time when Slash made the Story available to the public. See Section 4.2 later in this chapter for a description of this trickery.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Most of the daily work of a site takes place in the Edit Story form. It provides several controls to modify Story attributes and edit or preview Story content. This is the most complex part of the backSlash interface, yet it is easy to learn and convenient to use.

There are five ways to access the Edit Story form. Story numbers in the Stories list lead there. Logged-in Authors will see an Edit link following each Story on the homepage (see Figure 4-2, left) and an Editor link in the Author box at the top right of each Story's individual page (see Figure 4-2, right). Previewing a user submission from the Submissions list (discussed in Section 5.2 in Chapter 5) displays the submission in the form. Finally, clicking on the New link in the Admin menu brings up an empty Edit Story form.

Figure 4-2: Links to the Edit Story page for a given Story

At the top of the form, the Story Preview shows the basic Story information: the Intro copy, the Extended copy (if present), and the Related Links box. When first displaying a Story, the Preview will show the Story as it exists in the database (see Figure 4-3). New Stories, of course, have no Preview. Any changes made and previewed will update only the Preview. The database is updated only when an Author uses either the Update or the Save button.

Figure 4-3: The Edit Story form

The Related Links box is a little more sophisticated. Any time the Story is previewed or saved, Slash looks for keywords defined in the related_links database table. This table associates words with HTML links. For example, if the word "slash" occurs in the Story (and not as part of another word), a related link to the Slashcode site will be created. Some sites have used this to generate advertising revenue in a subtle Google-esque scheme. These can be edited through the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A weakness of server-based web software is that it depends on user web browsers to comply with established standards. Many web application developers have adopted a conservative strategy, requiring only the simplest common browser features. This attitude is particularly prevalent in the open source software community, since new browser features generally arrive first in proprietary forms, confined to particular makes of browsers on particular platforms. (For example, Javascript was initially an exclusive feature of Netscape browsers. Java support on the Macintosh has typlically lagged behind that of other operating systems). Proprietary plugins (such as Flash) may never be fully available to all client platforms.

To date, Slash requires no special browser features aside from HTTP/1.1, HTML 3.2, and RFC-2109-compliant browser cookies. Individual site administrators can configure their page layouts using more advanced HTML features, but Slash itself requires only the ability to accept cookies (used for user and Author authentication) and to submit HTML forms. Unfortunately, even these minimum requirements can be problematic, sometimes in fairly recent browsers.

Instead of merely redrawing the page, all but the latest versions of Netscape irritatingly reload the page from the server when the user resizes the browser window. If the page happens to contain an HTML form, it will probably lose the content.

Because backSlash requires a preview before committing a Story to the database, Authors will usually have the opportunity to spot these errors before publishing a Story. The potential for mishaps exists, though, so preview your Stories diligently.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A dedicated Author with a singular vision (and plenty of spare time) can search the Internet for worthwhile and informative ideas. However, a typical Slash site harnesses the powers of its userbase to find and recommend potential Stories. This can relieve the Authors from the often tedious task of continually scaring up fresh Stories, moving them to an editorial role. Slash provides several tools that enable Authors to filter, review, and polish user submissions into publishable gems.

Users submit Stories via the Submit Story page, available almost everywhere through the SubmitStory link. The Submit Story page presents a simplified version of the Edit Story page (see Figure 5-1). Its relative URL is /submit.pl. When a logged-in user accesses the page, Slash fills in some form values from the user's profile information. Otherwise, the form will contain generic Anonymous User information. In either case, users can edit or delete these values before submitting the form—even logged-in users can submit a Story anonymously. (As anyone who's seen All The President's Men can attest, all the best Stories require anonymity).

Figure 5-1: The Submit Story page presents a simplified version of the Edit Story page

A logged-in user will see a summary of his submissions (if any) at the top of the page. This information includes the date and time, Story subject, Section and Topic, and outcome (whether the Story is pending, was rejected, or was accepted and published) for each submission. The site administrator can control the frequency with which logged-in users can submit Stories with two configuration variables. A user can submit no more than max_submissions_allowed per day. They must be at least submission_speed_limit seconds apart.

As with the Edit Story page, the Story's text entry field comprises the meat of the Submit Story page. Jocularly labeled The Scoop, it accepts arbitrary HTML. In the hope of ensuring at least moderately functional HTML, users must preview a submission at least once before they can submit it. The preview appears beneath the Topic and Section menus and above the main text entry field. It reflects the changes Slash will make to the Story, placing the text of the submission in italics inside double quotation marks, attributed to the submitter:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Users submit Stories via the Submit Story page, available almost everywhere through the SubmitStory link. The Submit Story page presents a simplified version of the Edit Story page (see Figure 5-1). Its relative URL is /submit.pl. When a logged-in user accesses the page, Slash fills in some form values from the user's profile information. Otherwise, the form will contain generic Anonymous User information. In either case, users can edit or delete these values before submitting the form—even logged-in users can submit a Story anonymously. (As anyone who's seen All The President's Men can attest, all the best Stories require anonymity).

Figure 5-1: The Submit Story page presents a simplified version of the Edit Story page

A logged-in user will see a summary of his submissions (if any) at the top of the page. This information includes the date and time, Story subject, Section and Topic, and outcome (whether the Story is pending, was rejected, or was accepted and published) for each submission. The site administrator can control the frequency with which logged-in users can submit Stories with two configuration variables. A user can submit no more than max_submissions_allowed per day. They must be at least submission_speed_limit seconds apart.

As with the Edit Story page, the Story's text entry field comprises the meat of the Submit Story page. Jocularly labeled The Scoop, it accepts arbitrary HTML. In the hope of ensuring at least moderately functional HTML, users must preview a submission at least once before they can submit it. The preview appears beneath the Topic and Section menus and above the main text entry field. It reflects the changes Slash will make to the Story, placing the text of the submission in italics inside double quotation marks, attributed to the submitter:

Billy Miles writes, "As a multiple abductee, I must protest..."

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Logged-in Authors will see a link in the Admin menu labeled n Submissions, in which n is the current number of user submissions in the queue. Clicking the link leads to the Submissions list (relative URL /submit.pl?op=list). Similar in format to the Stories List, it summarizes the queued submissions, listing the oldest Stories first. This is the Slash version of a slush pile.

Slashdot, the mothership of Slash sites, receives several hundred user submissions per day. When a news story particularly dear to the hearts of its readers breaks, the queue may receive dozens of near-identical submissions. The Submissions list has several features intended to help Authors cope with this situation. It shows lots of information, so a wide browser window is necessary.

The table at the top of the page summarizes the distribution of current submissions across site Sections (see Figure 5-2). Only those Sections with queued submissions will appear. Clicking on either a name or a number will lead to a trimmed-down version of the list, showing only the submissions for that Section. This can quickly break a large list into manageable chunks. The Submissions link found on every Section's homepage also leads to the single-Section view of the Submissions list.

Figure 5-2: The Submissions list

The Submissions list displays the date, time, and subject of each submission, along with the nickname and email address given by the submitter. The subject is a link leading to the Review Submission page (described in the next section). A set of controls accompany each Story in the list. These allow rapid handling of the queue. The entire list is a single HTML form. Authors can choose an action for each submission in the queue, performing them all by clicking the Update button.

On active sites that receive many user submissions, most will be deleted. The subject alone may reveal that the submission duplicates the important Quake IV news already published. The Delete box is an unlabeled checkbox following each entry. All submissions with this box checked will be removed from the queue when the Author clicks the Update button. Unlike the Delete button on the Edit Story page, there is no grace period. Deleted Stories are gone for good (barring black magic), so exercise caution.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The final stop before a submission becomes a Story, the Review Submission page allows an Author to preview the text entered by a user. This page also displays any comments on the Story entered from the Submissions List page (see Figure 5-4). Slash automatically modifies the submission, italicizing the user's text and placing it inside double quotes. It also creates a default attribution at the beginning of the entry from the provided username and w

Table of Contents