--- todo: - Obtain more themes. Ideally, I'd be able to search themes on basis of popularity or voted rank; such themes are more liable to be well-constructed. - Create a "favicon.gif" file. Google "drupal favicon", first. Enable this and the logo below via the "Theme->Configure" panel. - Create theme-specific images -- for all themes we'll be enabling. (No point in enabling a theme if you're not going to skin it, eh?) - Establish mail-forwarding rules at nearlyfreespeech.net. In particular, perform the following redirections: - organicmechanics@raiazome.com -> alexis.pietak@gmail.com - morpho@raiazome.com -> leycec@gmail.com - Add a footer block having Forest Floor Organic's "Hosted by Raiazome. Powered by Drupal" text. - Write an equivalent of `oddmuse-mirror', targeting Drupal. Use the "Backup & Migrate" module to effect this; but, ensure that we archive the database without compression. Then, compress the plaintext database backup //and// set of all Drupal files via 7zip compression. (Comparisons of that with gzip and bzip2 show bzip2 as more space-efficient but less time-efficient than 7zip, and 7zip both more time- and space-efficient than either -- due both to 7zip's leveraging of multiple cores, on processors supporting that, and implementation optimizations.) While I wouldn't necessarily be interested in indefinitely archiving everything under Mercurial, due to the space costs, I do think I could maintain two backups: the most recent and secondly most recent backups. (Although, doesn't Mercurial perform compression on the backend? Actually, yes: it does. Mercurial repositories are automatically re-packed on each commit. Unfortunately... a packed Mercurial repository is not as space efficient as a packed git repository! Doooh. Oh, well. ;-)) For further details, see "backups" under "processes", below. - Definitely merge `oddmuse-mirror' into `hg-snapshot'. However, still spawn off a new, Drupal- specific script. As this script leverages neither rsync or Mercurial, it simply doesn't fit with the `hg-snapshot' mindset. Yum. drupal 7: synopsis (new): Forget it. Extensive crawling through the critical bug list shows a number of blocking bugs. Which will, probably, bite me. Given that, and the (more or less) utter lack of supported modules, and it's clear that I should just bite the bitter pill-bullet and go for Drupal 6.x. But... goshed darned it, I truly dislike MySQL. I reckon, I should still try it. (Can't help myself...) Wait. No. Don't do it. Just don't. Intuition tells me that this is an argument in the wings, waiting to happen. 7.x isn't ready. Get over it. ;-) synopsis: Probably half a year away, in terms of a stable release. It looks like it breaks backward compatibility, a bit, so there's module support to think of, too. --However,-- and this is a big --however,-- Drupal 7 provides explicit support for SQLite -- which, according to their latest bug reports, is passing all unit tests and working stably for several people. It's a slight risk, but might be worth it. drupal 6: advantanges: - extensive module support. disadvantages: - no sqlite support. (This is actually a larger disadvantage than one might suppose. Cost issue aside, I //will// be migrating Drupal to SQlite at some point. If I have to do it later, then I have to meet with a costy upgrade path, later. And who even knows if it would work, really? *blegh*) module support: Drupal 7.x does have //some// module support, but nothing like Drupal 5.x. For details, see the official module list for 7.x at: http://drupalmodules.com/category/7.x nfsn: reverse proxy: NFSN performs Squid-based reverse proxying on your behalf. Generally, this works well. Sometimes, it doesn't. (Due, principally, to Squid caching of stale Drupal pages.) For an insightful (and recently posted) fix, see: http://www.claws-and-paws.com/node/1256 sql: tables: comments: A table consisting of all comments for this site. nodes: A table consisting of all nodes for this site. users: A table consisting of all users for this site. modules: advanced help: !recommended! synopsis: Provides searchable, context-sensitive help -- for all other modules supporting this module. advanced theme settings: !recommended! synopsis: Several themes -- for example, our "Forest Floor" theme -- leverage this module to provide custom settings. Leech it, quick! backup and migrate: !!!!!!!recommended!!!!!!! synopsis: One of those "desert island" modules. Absolutely get. Yum, yum. Interestingly, by scheduling this, I can provide a local cron job (...or, perhaps, integrate with my existing "oddmuse-mirror" script? no; probably not :)) to fetch the most recent backup (since this module backs up to the server-side filesystem), and version control it. block cache alter: !recommended! synopsis: Permits per-block adjustment of cache settings: namely, whether or not to perform block caching on that block and, if so, how long to hold that block in the cache before expiry. bueditor: !recommended...but only if not installing FCKEditor! synopsis: An alternative to WYSIWYG HTML editors. While I probably won't install this for "Organic Mechanics," it is //probably// preferable to FCKEditor and other full-blown WYSIWIG editors -- for those prepared to confront a bit of HTML. It does provide a "Preview This!" button, and has highly customizable buttons (...for easy insertion of HTML tables, lists, images, and so on). It is //tremendously// smaller, simpler, and cleaner than FCKEditor, and produces, of course, clean, intelligible HTML. *shrug* cck: !recommended! synopsis: The Content Creation Kit, for customizing new content types. This module dependes on a host of other CCK-dependent modules for insertion of custom content fields. It's recommended you also download these. sub-modules: !recommended! - CCK Currency - Date - Email Field - File Field: ##deprecated## synopsis: Probably the most complex of the CCK field modules, as expected. In fact, it has a number of sub-modules, itself! Wait. This module is currently deprecated. I'd avoid it, personally. Drupal already provides a default upload widget. sub-modules: - download_count (...count the number of times attachments are downloaded) - Formatted Number CCK - Format Number API - ImageField: synopsis: Also quite a complex field module. Has various sub-modules; yadda! - Link - Money CCK field - Number - Phone (CCK) - Text checkall: !recommended! synopsis: Tends to be required by other modules. Simply provides "check all" and "uncheck all" buttons, when dealing with checkboxes. civicrm: synopsis: Ye bloody Gods! The heavyweights of heavyweights. This abstraction cluster- fuck is a non-profit, NGO-specific module for Constituent Relationship Management (CRM); that's right, yet another acronym. It does so via donor lists, fundraising, event management, and so on. Good God...a bit parasitic. comment subscribe: !recommended! synopsis: Sweeet. Permits users to subscribe to a thread of comments, such that Drupal will auto- email them on receipt of a reply to their original comment. Yum. contemplate: !recommended! synopsis: The Content Template (ConTemplate) module permits pre-processing of node content -- typically, CCK-constructed nodes -- via PHP templates, but in an interactive manner. (This module's typically used to prettify CCK output.) content profile: !recommended! synopsis: Adds the "profile" content type, for adding user, author, and administrator profiles. Sweet. currency exchange: !recommended! synopsis: Add currency exchange rates to nodes. ;-) cvs deploy: ...required, if installing 7.x from CVS... synopsis: Provides CVS-specific support, for CVS-specific installations. devel: !recommended! synopsis: Developer- and administrator-specific, of course. It provides a delightfully AJAX-propelled mechanism for debug-printing query statements, array contents, and so on; aesthetically pretty, it best resembles Firefox's FireBug extension. (Sweet!) caching: Interesting. It would appear that this module is the best mechanism for clearing the site cache. So... install away! drush: !recommended! synopsis: Probably intended more for Drupal development, than not -- but quite cool, all the same. Provides a bloody CLI environment from within Drupal. (Many other modules provide drush commands...so, sweet!) sub-modules: !recommended! - drush_extras e-commerce: synopsis: The "other" alternative to Ubercart -- but not nearly as well-liked, from forum readings. Ubercart would certainly seem to be the way to go, here. e-journal: !recommended! synopsis: No stable 6.x version yet, unfortunately. That said, this is probably the best lightweight alternative to the OJS (Open Journal System). Oh...there //is// a beta 6.x version, that looks quite respected. Essentially, this module permits publication of journal issues and, for each paper in said journals, spiffy citation lists, vocabularies, and so on. editing: fckeditor: !recommended! synopsis: WYSIWYG HTML editor, resembling TinyMCE. Both come quite recommended; but, according to most forums I've trolled (..and my own intuition, having examined their respective project pages), FCKEditor seems to have the edge. Stabler, better and better-maintained support for Drupal 6.x, and so on. One user notes: "A great WYSIWYG editor with a whole bunch of features. But it's a rather large download on each page. So, I usually keep it minimized, with the option to turn it on. This works well." installation: - Disable the "Line break converter" option. As FCKEditor already performs appropriate line- breaking on your behalf, it's best not to have Drupal perform it again, redundantly. link to content: !recommended! synopsis: Ties into other FCKEditor or TinyMCE, providing users a GUI-driven interface for linking to other extant nodes or menus. Nice. Note, however, that the official version does not support 6.x, as yet, while an unofficial version provided by the FCKEditor Drupal crew //does//. (Yum, yum.) wysiwyg filter: !recommended! synopsis: Quite sweet; provides an intuitive, GUI-driven mechanism for "whitelisting" HTML tags on a per-role basis. Supplants and, indeed, replaces the default filtering mechanisms bundled with most WYSIWYG editors -- like, say, FCKEditor. :) example: ___FCKsi___1___FCKsi___1___FCKsi___1@[id|class|style|title], a[href|name|target<_blank], div[alignafter" image and, well... it's a great space-saver! Get it. Yum. wysiwyg api: synopsis: Not recommended, at the moment. Basically, this will //eventually// probably be a nifty thing. But, currently, it simply doesn't work with FCKEditor. Eventually, it intends to provide seamless integration and communication with all WYSIWYG HTML editors for Drupal, such that one could (theoretically) hot-plug different editors in and out, easily. yui: synopsis: Yet Another WYSIWYG HTML Editor. Frankly, this is --probably-- the best of breed. But, it's heavy. We're talking ~200Kb worth of JavaScript downloads. Yes, this JavaScript //is// client-side cacheable. Probably. But FCKEditor, by compare, is only ~30Kb word of download time. Frankly, FCKEditor looks like a fine middle-of-the-road solution. Not as bare-bones lightweight as BUEditor, but not as heavyweight as YUI. YUI //is// the easiest WYSIWYG editor to install -- but only because, by default, it downloads all of its JavaScript from a Yahoo-hosted, external URL. *yawn* issues: backward compatibility: Drupal guarantess backward compatibility of data, but not code. That's fine; but does imply that modules tend to "die" as major version releases proceed. blank pages: Typically, a consequence of PHP having been delegated insufficient memory. "change own username" permission: synopsis: Hmmm. Most bloggers seem to think that permitting users to change their own username could be an issue. I don't necessarily see why that's the case. Shouldn't Drupal track users properly? Oh; but, I suppose it could be an issue. (Identity "borrowing," and what not.) public vs. private downloads: synopsis: To quote a blogger, "The "public" download method gives file URLs straight to where the file is stored. Drupal cannot offer any access control there. If you have the link you download the file. But it is a bit faster and trouble-free. The "private" download method gives URLs of the form "/system/files/filename". These are not real URLs, they are produced by Drupal. The real files can be even outside your web documents root, completely inaccessible. So, Drupal can allow or not allow the downloads for different users in different ways." purpose: To provide user- and role-specific content, segregated (and conceivably private) from other user- and role- specific content. This also prevents link-jacking of private images. That said, it introduces some (...or a lot of, depending on who you read) server CPU load, since Drupal becomes an intermediary security abstraction between the file and the Internet. Also, how useful are private images and files, actually? On "Organic Mechanics," for example, the authorized userbase consists of all users who've created a free account. But we want //all// users to be able to view images and files Alexis uploads -- and other users shouldn't be able to upload any. So, "private downloads" are, effectively, an expensive no-op here. url names: synopsis: Ah; I begin to get it. Clean URLs only remove the "?=" from the URL. To recieve better URLs, users should also enable the taxonomy module. This still isn't quite right, of course. URLs then resemble "/taxonomy/term/20/...", according to which terms are associated with that vocabulary. To associate a human-readable path to Drupal's auto-generated paths, enable the path module. Of course, this quickly becomes tedious...so, install and enable the pathauto module! Wow. Bizarre complexity, eh? overviews: - Great one, here! http://www.jonesfamily.us/ron-jones/internet/drupal/001-how-set-taxonomy-path-and-pathauto- drupal paths: sites/default: synopsis: Typically, contains this Drupal installation's default "settings.php" (u+rwX,g+rX-w,o-rwX) file, the "files/" (u+rwX,g+rwX,o-rwX) path, and not much more. The "files/" path is Drupal's file storage directory. It contains extraneous content downloaded by the Drupal subsystem, temporary files, and user-uploaded content, typically. (Quite intriguing...by sandboxing content here, they minimize security flaws.) sites/all: synopsis: Typically, contains modules applying to all sites served by this Drupal installation. processes: backing up: synopsis: Combine the raw power of "Backup & Migrate" and SSHfs-FUSE. How? Schedule "Backup & Migrate" backups to run every day. Then, by mounting the server-side repository over SSHfs-FUSE, retrieve those files to the localhost (...possibly repacking those files as 7zip), from where we then push those files to some path on the external harddrive and a path on SDF. Note: we can only store one such backup on SDF -- while, locally, we should be able to store a few. (Say, the most recent four or so?) Right. Having done that, then delete these files from the server. This deletion is optional, of course...Why? Well, the backup file will just be replaced the next time the "Backup & Migrate" module runs. We're not savin' much, here. :) filesize: MySQL statements compress well. Current backup bzip2-ed sizes are about 40kB. It should be noted, however, that our userbase and content is roughly minimal; and that this should balloon pretty quickly. Not something to store in Mercurial, in other words! module installation: synopsis: Quite simple. Simply unpack that module's tarball into "sites/all/modules/". If upgrading from a prior version of that module, you should follow a subset of the "upgrade path" instructions, below. (Basically, put the site into offline mode, run that site's "upgrade.php" script, and then put the site back into online mode. No need to Google this: that really is as simple as it is.) permissioning: synopsis: Under any CMS, all files should be user-readable+writeable, where the user is not the Apache user, group-readable, where the group is the Apache group, and other-nothing -- except for those files and paths which must be written to programmatically. For Drupal, such a path might be the "files/" directory, having user-uploaded files. Clearly, the Apache HTTP server must have write permissions into this path. tags: - Untrusted users -- which is most of 'em ;) -- should not be afforded access to embed "full HTML" in comments or user-submitted content. These tags, in particular, should be avoided: SCRIPT, IMG, IFRAME, EMBED, OBJECT, INPUT, LINK, STYLE, META, FRAMESET, DIV, BASE, TABLE, TR, TD, tags. These tags are called "advanced tags", in Drupal. - Always ensure the "HTML Filter" is the last filter in any filter chain. theming: synopsis: Drupal permits multiple themes to be enabled concurrently, but only one theme to be the default theme. This theme is the theme, as suggested, shown throughout the site for all nodes not having any specific theme assigned to them. In turn, as this suggests, individual notes can have other specific themes assigned to them! In any advent, enabling a theme also permits authorized users to select a theme under "My Account->Theme". upgrade path: synopsis: Drupal, given that it makes no backwards compatibility guarantees, is arduous to upgrade. The best, step-by-step walkthrough of this process is "Version Update Considerations" at: http://drupal.org/node/29161 sites: multi-site installation: synopsis: It's not an entirely simple problem. That said, Drupal ships with explicit multi-site support. Surely there must be a decent document, somewhere, on this topic? Ah-hah! See: http://drupal.org/getting-started/6/install/multi-site http://drupal.org/node/290768 // <----- ! THIS is the great one! process: Follow the process as outlined by "http://drupal.org/node/290768", above. It's //very// simple, actually. Copy default settings to the new site folder, manually modify //before// accessing the new site (so as to setup the new site's database and user), copy the "install.php" script into the new site folder as well, and run it via an external browse. Simple! (Wow. Nice 'ne, Drupal. ;-) observances: - Each site should have a unique "files/" path; conflicts arise when they share the same. (See "admin >>> files".) - Each site should have a unique "sites/" path, corresponding to that site's FQDN; e.g., "sites/organicmechanics.raiazome.com/settings.php" "sites/davidcurry.raiazome.com/settings.php" - Each site should have a unique database, rather than sharing tables of one database (with some site-specific prefixed tables for necessarily unique tables). Generally, this isn't an issue. NFSN, for example, permits creation of infinitely many MySQL databases within one MySQL process. Yeah! users: by name: leycec: Administrator permissions. alexis: Page-authoring permissions. by uid: 0: The anonymous user. Has no permissions, effectively. 1: The root user. Has all permissons, always, regardless of which roles are assigned to this user. roles: default: authenticated: users having already registered and logged on anonymous: users not having registered or logged on additionally suggested: - site admin - user admin - site contributor terminology: access rules: synopsis: A user management tool. Essentially, this permits site admininistrators to forbid creation of new users with usernames, e-mail addresses, or IP addresses matching some patterns, or login of existing users matching similar patterns... Unsure how much broad applicability this has, really. approval queue: synopsis: Comments submitted by users for which the "post comments without approval" checkbox is not checked are automatically added to Drupal's "approval queue." This is a list of checkboxes visible to comment administrators, with one checkbox for each unapproved comment, which when clicked approves that comment and makes it visible for all users. This is a bit heavyweight; I'd prefer a Bayesian filtering spam to auto-catch spam or unkind comments. ;-) openid: Since Drupal core supports OpenID (...and so will Organic Mechanics), required non-logged-in users to submit comments for approval isn't much of a hassle. "Just login with OpenID, if you want to post uninhibited!" block: synopsis: A set of grouped content in the left or right sidebar -- usually, auto- generated by modules but occasionally authored with static content. sorting: Blocks are sorted by weight via the Block Management screen. "Lighter" blocks float upward; "heavier" blocks sink downward. throttling: Blocks marked throttable are hidden during high server loads. clean urls: synopsis: A Drupal-specific standard. By default, Drupal URLs resemble: "http://www.example.com/?q=node/8". With clean URLs enabled, this becomes: "http://www.example.com/handbook/drupal/node/". header tags: synopsis: Interesting suggestion, here. Perhaps this is why Usemod insisted on level 2 headers? "There should be one

header element on every page and it should have your keywords in it." (Makes sense! Yeah. Another SEO thing -- but also an aesthetic thing, really. This probably improves CSS customizability as well, come to think, by ensuring that only titles ever use the

tag.) install profile: synopsis: Provides a prepackaged Drupal installation (as opposed to the clean-slate default). examples: e-Journal: Prepackages a configuration suitable for constructing an open- source academic journal. multi-site installation: synopsis: A Drupal installation in which one Drupal codebase serves multiple sites on the same domain. Quite helpful! I'll want to look into this for David, I think. node: synopsis: A node is a Drupal page. A node type, therefore, is a category of Drupal pages. (Note that "node types" are officiously called "content types," now.) By default, Drupal enables two node types: page and story, with no semantic difference between the two. Common examples of other node types include: "blog entry," "book page," "forums," and so on. content: By default, a node only stores two fields: a "title" and a "body." Addition of custom fields (metadata) requires the CCK module. usage: creation: Custom node types are creatable via the Drupal core -- but only customizable via the CCK (Content Creation Kit) module. Such customization includes addition of further fields to custom node types. An example of a custom node type might be a "course list." This would be a page listing all courses on offer and for each such course course its title, description, duration, and cost. types: page: A static node, typically of some permanent importance. story: A static node, typically of no permanent importance. News items and changelog comments are two examples of "stories." One slight difference between pages and stories is that stories are automatically promoted to the frontpage and allow comments, by default. region: synopsis: I'm not quite clear on how this differs from a block. (It's probably a theme authoring-specific term, I reckon.) role: synopsis: An authentication abstraction. Users are not assigned permissions directly. Rather, one or more permissions are assigned to a "role;" then, one or more "roles" are assigned to a user. This, of course, resembles Linux-style group/user management. (Roles are groups. Simple!) seo: synopsis: [S]earch [E]ngine [O]ptimization. Programmatic heuristics for improving Page Rank, basically. sticky: synopsis: A "sticky" page is a static page. Generally, such pages are used to mimic olden-day style, HTML-based websites. taxonomy: synopsis: A hierarchy of nodes. Also perfectly synonymous with "category." Taxonomies are dynamically constructed via the hierarchical term(s) associated with those nodes. teaser: synopsis: Node views are classifiable as either "teaser" or "full." Clearly, the teaser node view for a node is a brief synopsis of that node's full content. Note that, by default, Drupal clips the teaser from a node's content by substringing the first however-many characters of that content. However, you can control this by manually inserting the Drupal-aware HTML comment. Yum. Fairly hackish... but, it makes sense. Fortunately, FCKEditor has a plugin to manage this. template: synopsis: Not what it tends to mean, traditionally. Here, a "template" is a collection of XHTML, CSS, and PHP snippets that, in some, produce a Drupal site's look and feel. "templates" and "themes" //are// perfect synonyms, here. term: synopsis: A category or tag or keyword, typically assigned to a node. Terms are the //only// hierarchical aspects of Drupal. All terms assigned to a given node are typically displayed by the current theme; when clicked, Drupal displays all other nodes also assigned to that node. menus: Nice! A term can be assigned to a menu item. Since terms, themselves, are assigned a unique Drupal URI (by default, "taxonomy/term/${term_id_number}" where the ${term_id_number} is a number beginning from 1 which Drupal auto-assigns each term when that term is created) and menu items link to Drupal URIs, a term assigned to a menu item means clicking on that menu item shows all nodes associated with that term. This could be great, for example, for classifying journal papers and books. It's a tagging mechanism... Mmmhmm! Sounds good. naming: It would seem best to use plurals when naming terms. Why? Well, assuming decent paths, the path to see all books could resemble "taxonomy/term/books". Yum. I think, anyway... modules: - Taxonomy Menu module! Nice. Auto-converts a hierarchical taxonomy into a menu. (Oh, yes.) We could use this to implement a vocabulary resembling: oeuvre \----> books \----> papers \----> poetry \----> artwork Hmm. Perhaps, not such a good idea after all. After all, I'll probably want to construct this menu manually so as to control ordering. Not particularly difficult, eh? Oh, yes -- and Googling this module gives this blogged tidbit: "This can be a problem for example when you want to use a module like Pathauto to automatically generate URL aliases. The pages created by the Taxonomy Menu module are not managed by the Pathauto module. So if you want to keep a coherent naming system for your URLs you will need to change manually the URL aliases for these pages." Ugh! Forget about it, eh? examples: - If the term "sonatas" is term 1, then "taxonomy/term/1" calls for all the nodes of that category. - If the term "Bach" is term 2, then "taxonomy/term/1,2" calls for only those sonatas written by Bach. (The comma, here, is an "and" symbol.) - If the term "Brahms" is term 3, then "taxonomy/term/2+3" calls for everything that has to do with either Bach or Brahms. (The plus, here, is an "or" symbol.) - If you are using a hierarchical taxonomy, and want all notes tagged with child terms to show up also, you can create an URL link like "taxonomy/term/2/2" where the second parameter is the depth that the tree will be recursed into, or "taxonomy/term/2/all" for all child terms. theme engine: synopsis: A PHP templating engine for use in skinning Drupal themes. However, as Drupal provides a default engine, which nearly all themes leverage, this is a bit extraneous. heuristics: - Avoid fixed-width themes. They tend to render horizontally-long tables (unusably) poorly on screens of at or less than 800x600 dimension. They clip off the tables' ends... user pictures: synopsis: A picture to be displayed alongside user comments and posts. Enabled via the "User Settings" menu and, for each theme, must also be specifically enabled. vocabulary: synopsis: A collection of terms. Vocabularies belong to no hierarchies. So, a site has multiple vocabularies (flat), each having multiple terms (hierarchicalized). association: Child vocabulary terms may be associated with a single parent term or multiple parent terms. free-tagging: "Free-tagging" vocabularies permit users authoring node content to assign arbitrarily user- defined terms to that node content, rather than assigning static terms as defined within that vocabulary by the site administrator. technology: ahah: synopsis: [A]synchronous [H]TML [A]nd [H]TTP; resembles AJAX. In AJAX, the server typically sends XML, JSON, or similarly structured bits of plaintext, which the client then parses into proper [X]HTML via client-side JavaScript; in AHAH, the server sends fully-formatted [X]HTML to the client. The tradeoff, here, is as expected: speed. Generally, one should use AHAH -- due to its improved client-side responsiveness -- rather than use AJAX -- unless one has a strong need for client-side "intelligence," whereby the resultant [X]HTML can only be parsed together on the client- side. blueprint / 950gs: synopsis: Two alternative, but quite similar, CSS frameworks. Essentially, they provide sane CSS defaults. A site-specific CSS file includes (cascades) the CSS file provided by these frameworks prior to performing site- specific overrides. Makes sense, if a tad heavyweight. (New themes tend to use Blueprint or 950gs, purportedly. By God, but isn't Computer Science becoming even more heavily differentiated? All quite unnecessary, this tripe is, it seems.) curie: synopsis: A standard for embedding [C]ompact[URI]s within XHTML data. These actually resemble Oddmuse-style interlinks, to a remarkable extent. jquery: synopsis: A sweet JavaScript file. That's right: one file. It provides a remarkably coherent framework for JavaScript<->HTML communication, DOM traversal, AJAX integration, et al. Drupal uses jQuery extensively. meta description: synopsis: The ... section in an HTML page may contain a ... string. This is, actually, the second-most important function of the meta section (...the most important function being definition of a page's title). This string is the string search engines present beneath the page title for a search hit. Nice! I always wondered how that worked. Heh. openid: synopsis: Wow! Sweet. Permits "https://" connectivity without having to purchase an official certificate. (Essentially, you create an OpenID with a third- party. We probably already have Google-powered OpenIDs, no?) issues: gmail: To quote a recent blogger, "Google is *not* a standard OpenID like Microsoft and Yahoo. Even according to their terms if you go in and check them, they have something that *resembles* an Open ID….but is not a true OpenID. Zoho is just one of the first sites that actually adopted their ridiculous form of it. This is not a step forward for the whole OpenID process...Google just again manages to screw things up by having to be different. Whether it was to prove a point, say "our way is better" or whatever...who knows. There are entire extra steps that their process follows that a true OpenID process does not; and renders it incompatible with most sites." solution: To quote another blogger, "Well, just tried using Google and checked on the OpenID mailing list and they are NOT compliant. You have to type in http://www.google.com/accounts/o8/id if you want to use Google on an RP that has not implemented Google’s magic extensions. Very disappointing." insanity: To lastly quote this blogger: "With OpenID, the user memorizes a web URI, and provides it to the sites he or she would like to sign in to. The site then POSTs an OpenID request to that URI where the OpenID backend server proceeds to perform the requested authentication. In Google's version of the OpenID "standard," users would enter their @gmail.com email addresses in the OpenID login box on OpenID-enabled sites, who would then detect that a Google email was entered. The server then requests permission from Google to use the OpenID standard in the first place by POSTing an XML document to Google's "OpenID" servers. If Google decides it'll accept the request from the server, it'll return an XML document back to the site in question that contains a link to the actual OpenID URI for the email account in question." links: - "Google Doesn't Use OpenID." (Great post. Heaps of ranting and raving. ;-)) http://neosmart.net/blog/2008/google-doesnt-use-openid/ - Google's non-compliant OpenID "standard" documentation: http://code.google.com/apis/accounts/docs/OpenID.html rdfa: synopsis: A standard for embedding RDF data within XHTML data. Largely irrelevant, for those unconcerned with social networking. rel="nofollow": synopsis: A search engine-specific standard for marking a link on some site to an external site as a link that should //not// contribute to that external site's Google PageRank. xri: synopsis: A W3C standard, subsuming the URI standard. (XRIs are a "larger" concept than URI. URIs are representable as XRIs --and-- vice versa.) They have principle use as an intra-organizational structuring tool. For example, a library system could refer to individual books at individual libraries with an XRI partitioned into a DNS library reference and ISBN book reference, like so: "xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)" xsrf: synopsis: A [C]ross [S]ite [R]equest [F]orgery exploits the trust that a site has for a user. Typically, a user is convinced (or manhandled) into clicking on some URL (...say, "http://site.com/stocks?buy=100&stock=ebay"), typically by inclusion of that URL in spam e-mail or website, which, if that user is logged into that "site.com", causes that POST action to be triggered. Quite simple, really. xss: synopsis: A [C]ross [S]ite [S]cripting attack exploits the trust that a user has for a site (or application). Typically, a user is convinced that that site (or application) is trustworthy -- when, actually, it isn't. Usually, that site is //supposed// to be trustworthy but, due to the injection of malicious code into that site by another user, that site has implicitly lost its trust -- while everything, to the benign user, still appears decent and trustworthy. Agh! same origin policy: A policy, used by most noteworthy browsers, to prevent script code (typically, JavaScript) loaded from one "origin" (top-level domain) from accessing script or file code or data from a different "origin" (top-level domain). Since a user's filesystem is also considered an "origin" (i.e., "localhost"), this policy prevents JavaScript from munging not only the JavaScript, cookie files, and other cache files from other sites but also the local filesystem. optimizations: synopsis: All (or most, anyway!) optimizations enumerated below should be enabled prior to taking a site live. drupal: heuristics: - Use simpler themes. CSS and image files for Drupal's default "Garland" theme account for up to 50% of each page size. Other themes are much larger with more CSS, images, and JavaScript. Speed up a site by using a simpler theme with fewer files to download on every page. - Avoid slow blocks; avoid many blocks. Every block you add to your site's page layout increases the time Drupal uses to assemble each page. Many blocks also add style sheets, images, and scripts to your pages. While enabling a block cache can help, you can speed up the site further by simply not using as many blocks. - Don't both leveraging HTML or CSS "optimizers." All these products is, essentially, remove whitespace; this added complexity does slightly reduce resultant file sizes but, since the limiting factor for most decently fast connections is now network latency (that is, time spent issuing client requests to the remote webserver and returning the results to your local ISP) rather than network bandwidth (that is, time spent receiving those results from your ISP), these modestly saved bytes are of little consequence. css aggregation: synopsis: Via Google, "Drupal has a main style sheet. Each module may add its own style sheet. Your site's theme has one or more style sheets. For a complex site, these style sheets can be large. Combining them with Drupal's CSS file aggregation feature reduces their size and creates just one file to download, instead of many. This is such a clear win that every site should enable aggregation before it goes live." latency: As network bandwidth goes up, the time to send the data goes down, of course. But whether you're on a fast or slow network connection, there is always about the same amount of latency or delay time between asking for a file and receiving that file. On a slow connection, that latency is a minor factor compared to the slowness of the connection. But on a fast connection, latency becomes a dominant factor. The more files your web page needs from the server, the more file requests the browser must issue and the more time is spent waiting because of network latency. Since you can't make the network latency go away, your best fix is to reduce the number of files you need per page. This is the principal benefit of CSS file aggregation. process: - Check "Administer » Site configuration » Performance » Aggregate and compress CSS files." - Click "Save." Voila! links: - "Speed Up a Drupal Website by Enabling CSS Aggregation." (Great post!) http://nadeausoftware.com/articles/2007/03/... block cache: synopsis: Tricky. Ideally, module blocks would have sufficient intelligence of which sort of block caching they require and permit the user to enable that. Unfortunately, Drupal (as of D6) does not provide such an API. Consequently, Drupal administrators must, themselves, ascertain which blocks to cache and how to cache them. There is considerable room for error, here; as such, and as caching every block introduces increased complexity and slow- down, it is best to only explicitly enable block caching for particularly slow blocks. These tend to be blocks performing a wide array of database queries. We list several of the more slowest, commonest blocks, below. slow blocks worth caching (...although, there are doubtless more!): - The Comment module's "Recent comments" block. Quite slow. - The Event module's "Calendar to browse events" block. Somewhat slow. - The Image module's "Random image" block. Quite slow. - The Poll module's "Most recent poll" block. Marginally slow. - The Similar entries module's "Similar entries" block. Somewhat slow. - The Weather module's "System wide" block. An unusually slow block. testing: During testing, include both the non-cached and cached block on your pages. Once everything is working, disable the non-cached block. process: - Consider installing the "block cache alter" module. (See "modules," above.) - O.K.; this is quite complex. Here goes! - Check "Administer » Site building » Modules » Block Cache." - Once enabled, this module automatically creates a duplicate cached version of each of your site's blocks. For example, if you have a menu block named "Navigation", the Block Cache module will create a new cached block named "Navigation [[-CACHED-]]". By default, these are all disabled. Enable them as you would customary blocks; i.e.: - Visit "Administer » Site building » Blocks" and enable "[[-CACHED-]]" blocks. Note that, during debugging, it is common to include both the non-cached and cached version on the page at the same time. Once everything is working, disable the non-cached block. - Configure each cached block on that same page. D6 provides three principle options for configuring this; these are: - Cache type. Check one, both, or none of these: - Page specific. Indicates the block should change on every page, such as a block that shows taxonomy terms for the node on the page. - User specific. Indicates the block should be different for different users, such as a menu block with special menu items only for administrators. - Cache lifetime. Select the longest time (in seconds) before the block will be automatically rebuilt. By default this is blank, implying that cached blocks are only rebuilt when site content changes (via the "Refresh when" option, below). - Refresh when. Check none, some, or all of these: - A node is added/updated/deleted. Indicates the block should update each time any nodes change at the site, such as for a block that lists recent blog or forum posts. - A comment is added/updated/deleted. Indicates the block should update whenever someone adds or changes a comment, such as for a block that lists recent comments. - A user is added/updated/deleted. Indicates the block should update whenever user accounts are changed, such as for a block that lists new users. - A user logs in or out. Indicates the block should update when users come or go, such as for a block that lists the people currently logged in. page cache: synopsis: Speed up page load times for anonymous users by saving commonly-used web pages in Drupal’s page cache. synchronicity: Pages in the cache expire and are thrown out after the Minimum cache lifetime. Changes to a cached page will not be seen by visitors until the page expires. To see changes sooner, set the lifetime to a shorter value. issues: Logged-in users do not benefit from the page cache and, even for anonymous users, the page cache is not synchronized with content changes. That said, the speed benefits (of up to 40% for complex pages served to anonymous users) suggest this is well worth enabling. Via Google, "Logged-in visitors may have unique account permissions and preferences that shape how Drupal builds web pages. Since each logged-in visitor may be different, Drupal must generate a custom page for each one. It cannot use the page cache." process: - Check "Administer » Site configuration » Performance » Caching » Normal." (Do not enable "Aggressive" caching, as that tends to play poorly with third-party modules.) - Set the minimum cache lifetime to, for example, 1 day. (86,400 seconds.) apache: {see "optimization" under "apache.note"} mysql: {see "optimization" under "mysql.note"} php: {see "optimization" under "php.note"} resources: handbook: http://drupal.org/handbook cookbook: http://drupal.org/node/120612