To make my wiki more bloggable, I need to make some changes.
Starting point:
Deal with spiders/robots
Want to be indexable by Google, etc. But don't want to wipe out my server with pointless traffic.
Plan
- change standard page meta tag (default is 'index,nofollow')
change 'map' and 'Back Links' to use POSTs so that spiders won't follow them
- later (Jan'02) did the same for the Edit link so that all the edit forms wouldn't get included in the search engines.
Implementation
- change standard_wiki_header (and standard_wiki_footer, which is missing a close-form tag)
change ZWiki Parents.py:
line 109, to always set 'suppress_hyperlink=1' (so that page title doesn't link to Back Links)
- line 122, to suppress the first line in the 'ul' page hierarchy that links to the map
Support all-caps Wiki Name creation (e.g. PDA)
Add wikiname3 to ZWiki Regexes, add to simplewikilink and wikilink lines.
Some annoying new Wiki Names: OK, US, USA, NYC; every state address (an issue if using for PIM - though I suppose I could tweak the pattern then to make this only work for a word with at least 3 letters...) (Jan9'02 tweaked wikiname3 to skip 2-letter abbreviations)
Later tweak (Jan'02): explode titles
For search engine indexing, want a page's Wiki Name/id to be exploded into separate words. Decided to focus on doing it in the 'title' tag, which is sometimes weighted more heavily
first made new method 'title_exploded(self, title)', but couldn't seem to pass the value properly from the DTML for the header.
- so decided this approach wasn't necessary, could just call 'title_exploded(self)', and reference the current object id right within the method.
but kept getting output of 'Python Method Object at ....'. After seeking help on ZWiki site, finally did research myself, and discovered that I needed to reference not 'str(id)' but 'str(getId())'. Now it works.
Custom Web Log view
See Thinking Space for overall spec. Current issue is how to make a custom version of the Recent Changes page, which would show full rendered text for blog entries, and probably just name for true Wi Ki pages.
note that The Brain of Jerry Michalski has 31k entries. So eventually I could have more true-wiki notes than blog nodes. Does that make this distinction less important?
Some options for distinguishing blog entries from wiki pages (see discussion at WikiLogNameSpaces)
- special name for blog entries
was going to use something like 'B20011231 A' (where that first letter is 'B' for blog and 'D' for diary, and the final letter creates the uniqueness for multiple entries on the same date). A regular expression could handle this, but unfortunately can't use regex in DTML, or even, per Simon, in Python Scripts.
so, to be able to use core 'string()' ops, probably easier to start blog and diary entries with a single token, so it becomes something like 'XXB20011231 A'. Or maybe using lower case makes it easier, since you'd almost never want to do such a thing in a regular Wiki Name, even one created via square brackets.
Decision: keep blog plus wiki entries all in one folder. Start blog entries with lower-case 'z'. See Web Log Index.
- put blog entries in subfolder
because of acquisition, blog entries could reference a core Wiki Name, and that link would work.
at the moment the link gets activated, but points to the subfolder, so when you click on it, you get a not-found error. This is related to 'context', whatever that means (there's some old crummy code, which you can escape by turning off the User Options showing the page hierarchy, which sux). It might be possible to work around.
there's another issue with this design, which is if you want to start a new wiki page because of a blog entry, you might be tempted to write the Wiki Name in the blog entry, then click on the question mark. But that would be a mistake, because it would create the new wiki page in the blog subfolder. So you have to be disciplined about this, which might make it a bad general solution...
also, Back Links from a wiki page won't include blog entries. Is this a good thing?
- make a separate meta-class for blog entries. This sounds like the biggest pain in the butt.
Rendering multiple entries to a single page: I looked at the Python rendering code, and realized that one big method renders the entire page (including header and footer). So was afraid I'd have to do a nasty re-factoring. But then noticed the way that GeneralDiscussion is pulled onto their FrontPage, and decided to see if there might be an easier approach. The aha! is that if you use DTML to include content from other pages, then the current containing page handles the rendering for you, so you don't have to worry about rendering out each included page on its own. That should make things lots easier. See Web Log Output for first cut.
Need more-changes using the batch-control part of 'dtml-in'. (Actually, for older entries, probably want (a) to list blog entries by create-date (id) rather than mod-date, and (therefore) (b) separate blog entries from wiki pages.)
created Web Log History (sorted by create-date (actually by id)), Wiki History (sorted by mod-date); both use batches. Later created Biggest Pages, which sorts on get_size (to find some of the meatier stuff).
Web Log Output was moved to become Recent Changes; the original Recent Changes was moved to All Changes. Then copied Recent Changes to become Front Page.
note that for any page to render the Structured Text, I have to change the property page_type to structuredtextdtml (which is what new wiki pages default to) instead of just htmldtml (which is what Recent Changes used to be) or structuredtext (which is what Front Page used to be)
(Should think about rendering/cache issues for performance purposes...)
Speed Web Log Entry see notes/log there (Mar'02)
Touch Graph Wiki Browser view - Marc Conley provided code to generate data file (May'02)
Added 'LINK' Meta Tag to point to (Les Orchard's) RSS feed. (Aug'02)
Changed Search Page results to look like Front Page (sorted by mod-date, same table format). Plus applied that sort to Back Links page: would like to make prettier, but method results can't automatically be rendered - did an ugly hack for now to show first 50 chars (unrendered), will revisit later.
- should probably reverse the rules for doing searches - default behavior is to use a leading '!' for a full search, else it searches just titles and if finds any match takes you right to the first one. Blech.
<hr>
next steps (toward Future Wiki Weblog Features) will be:
improve validation of HTML (esp. Web Log Output). Maybe via CSS?
- probably upgrade codebase before making any more substantive changes
<hr>
How about an option to show diffs for wiki pages which have changed, up to a certain size? --John Abbe
reply: yeah, once I upgrade my code base I'll be looking at that. -Bill Seitz
<hr>
Kewl. I've been looking for something like this. I wanted to update zKnowMan (on Zope.org), to include ideas from www.welchco.com (he posted his SDS source a while back). Are your zWiki mods available in one easy spot, or do you have a zip file for a shleppy Windoze user like me 
I have a iMeme account and a Windoze server on a T1 all by itself :^) I've also been doing some work on the Save On Client and Save On Server Problem
<hr>
Are any of your changes available in source form? I'm interested in duplicating some of them under CMFWikiand would rather not recreate the wheel. - J C Lawrence mailto:claw@kanga.nu
reply: sure, just email me, and I'll send you a file which when imported will provide a folder with some DTML files to copy into your regular ZWiki folder. -Bill
<hr>
Get back to some customization, on my private machine, to work with ZwikiTracker.
Goals:
- get generic stuff backfit (e.g. moved/updated from public zwiki)
have lost custom python code for custom Wiki Name rules, etc.
dynamic weblog pages seem broken, probably an issue with new page types. Also want to see whether there's a custom mod-date field now, so it can be manually controlled (and maybe even a per-change Comment, which could be used in listing pages for non-weblog wiki pages). (Or instead could list the first line for each wiki page, like in http://openspirit.homelinux.net/noowiki/AllPagesWithAbstracts)
Issue Tracker - see whether it meets Project Flux needs for a Small Co (though obviously wouldn't handle cross-org views). (Can you hack a hierarchy? How make a Web Log/App Log of notes tied to each issue?)
Issue Tracker work
Nov15'02
copy over How To Install AZwiki Tracker, which refers to How To Install AZwiki Catalog
make new empty folder 'issues_blank' (the idea is to do the setup, then keep this empty, and copy the folder when I want to create a new wiki with the catalog and tracker already set up)
Nov20
create the catalog per How To Install AZwiki Catalog
follow How To Install AZwiki Tracker: add properties (are they really hardcoded elsewhere? yes, see for example top of Issues View form), copy form (call it Issues View) and make it the right type. Copy Filter Issues. Don't create mailer support.
- now copy folder to 'issues_test' to start entering fake data.
- enter first dummy record
fails: seems to be submitting to Zwiki Tracker instead of Issues View! Instructions specifically said to name the form differently. And looking at the code for Issues View, all the form submits seem to be to its own dtml-driven URL, not hard-coded at all. And doing a view-source shows the submits to be that current custom URL. Maybe a redirect?
comment (9/23) in instructions page says that Tracker.py has that name hard-coded! So tweak it to use Issues View. Restart. Still seem to be getting same error.
- But now discover that the issues have been added anyway (even from before the tweak)! Also play to note that
- there's no assignment fields, so clearly task tracking for a team will require some customization!
can edit the body of an item (to add a progress note if I want). This changes the sort order, and also Recent Changes
Recent Changes displays the 'title' of each page, rather than its Wiki Name. (I'm used to thinking of them as the same thing. The distinction is probably what drives that weirdness in the diary where weblog entries start sometimes with a lower-z and sometimes an upper-Z, breaking some links.) So for issues you see the title (with spaces) instead of the id/number. Should probably see both.
all issues have Issues View as a parent. And this shows up in the header of each. Also see there are left/up/right arrows in the single-issue view. Will need to check what happens if I play with the hierarchy (e.g. make one issue the parent of another, give an issue multiple parents, etc.)
editform includes an 'Optional note' field to associate with an edit. But this doesn't show up in the Recent Changes listing. But it does show up in the 'diff' view. And there's no 'minor edit' checkbox (to avoid updating mod-date).
Duh, just realized that 9/23 comment related to what gets hit when you click the "up-arrow" link when viewing a form. So it's not relevant to my problem! See Zwiki Tracker hardcoded into mailin.py, but that doesn't seem like a likely suspect. Post question to zwiki.org.
Duh again, there was a hard-coded redirect in the DTML for the page, that even had a comment next to it saying it needed to be renamed. Fixed that, and it works fine now.
Nov21
notice that there are some issues/bugs which have been open a long time. Dean Goodmanson recently posted similar concerns, asking about a dev plan, and I didn't see a response, so I emailed him to see what's up...
- Decide not to worry about it for now.
Dec4
tweak Issues View look a tiny bit. Copy back to 'issues_blank' folder.
- Want to start supporting assigned-to property. Decide to call it 'assigned_username'.
consider idea of having it tied to ACL file, decide to keep it simple for now, mimic the approach used for the other custom properties, just manually populate a list (that's a bad idea long-term, as it requires adjusting that list manually).
also decide to use full Firstname Lastname as standard (vs Firstname Lastinitial or other nicknames).
- copy 'issues_blank' folder to 'issues_assigned'
tempted to replace the 'issue_categories' property, since I'm going to want to use the Hierarchal Structure. But decide others might disagree, so will just add new property.
- add the 'assigned_username' property. Assign some dummy values.
add 'assigned_username' Field Index to catalog. Also add to catalog's metadata list. Updated the catalog, just because it seemed like a good idea. Tsk Tsk.
Dec6
added enough code to Issues View form to make User Name selectable, but with no handler.
- created an Issue, no errors. (Of course no property set)
- * added more code to handle UserName property. Now can't save the form
- Document Template Parse Error
Traceback (innermost last):
File D:\Zope\Web Seitz\lib\python\ZPublisher\Publish.py, line 150, in publish_module File D:\Zope\Web Seitz\lib\python\ZPublisher\Publish.py, line 114, in publish File D:\Zope\Web Seitz\lib\python\Zope\init.py, line 159, in zpublisher_exception_hook
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\ZPublisher\Publish.py, line 98, in publish File D:\Zope\Web Seitz\lib\python\ZPublisher\mapply.py, line 88, in mapply
- (Object: edit)
File D:\Zope\Web Seitz\lib\python\ZPublisher\Publish.py, line 39, in call_object
- (Object: edit)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 2012, in edit
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 2083, in _handleEditText
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 2338, in _setText
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 231, in _preRender
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 210, in _render
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 374, in render_stxprelinkdtmlhtml
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\ZWiki Page.py, line 322, in cook
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 170, in parse
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 223, in parse_block
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 170, in parse
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 223, in parse_block
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 170, in parse
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 223, in parse_block
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 177, in parse
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Document Template\DT_String.py, line 58, in parse_error
(Object: Issues View)
Document Template Parse Error
Dec12 - step back try again
- (crashed and lost changes anyway, so back at state where have form field, but no handlers. So no crashes.)
- * add
newassignedusername="_.getattr(REQUEST,'newassignedusername','Bill Seitz')"
that was OK
- * now realize I have to change code within Tracker.py
- issue.manage_addProperty('assigned_username','assigned_username','selection')
- issue.manage_changeProperties(page_type='issuedtml',
- title=title, category=category, severity=severity, status=status assigned_username=assigned_username )
- issue.manage_changeProperties(page_type='issuedtml',
- * then had to change changeProperty() code, duh. Then fix a missing comma. Now new error
File D:\Zope\Web Seitz\lib\python\Document Template\DT_Let.py, line 76, in render
(Object: newcategory="_.getattr(REQUEST,'newcategory','zwiki: general')"
newseverity="_.getattr(REQUEST,'newseverity','normal')" newstatus="_.getattr(REQUEST,'newstatus','open')" newassignedusername="_.getattr(REQUEST,'newassignedusername','Bill Seitz')" newtext="_.getattr(REQUEST,'newtext','')") File D:\Zope\Web Seitz\lib\python\Document Template\DT_Util.py, line 159, in eval
(Object: createIssue(newid,newtext,newtitle,newcategory,newseverity,newstatus,newassignedusername,REQUEST=REQUEST)) (Info: newtitle)
File <string>, line 2, in f File D:\Zope\Web Seitz\lib\python\Products\ZWiki\Tracker.py, line 163, in createIssue
(Object: Issues View)
File D:\Zope\Web Seitz\lib\python\Products\ZWiki\init.py, line 163, in manage_addProperty
(Object: Issue No0004)
File D:\Zope\Web Seitz\lib\python\OFS\Property Manager.py, line 248, in manage_addProperty
(Object: Issue No0004)
File D:\Zope\Web Seitz\lib\python\OFS\Property Manager.py, line 171, in _setProperty
(Object: Issue No0004)
Bad Request
- * somehow get it in my head that 'username' might not be a good property name, so I change
- issue.manage_changeProperties(page_type='issuedtml',
- title=title, category=category, severity=severity, status=status, ausername=ausername )
Everything works! Issue No0006 has the right property. Left Issue No0005 with wrong property name.
Change that code. View issue. Looks OK except that 'Bill Seitz' in pulldown has a question mark after it. Oy, is it rendering wikinames?
Yeah. Added Bill Seitz page, and question mark went away. Of course it was still there for the dummy User Name values. And when I did a viewsource on the HTML, it was clearly there. Blech. Wrong page type? Problem doesn't occur with Issues View (Issue Tracker list).
Not sure how you're storing the names, swiping the list from another page or a property, but could you store them as: BillSeitz JohnDoe, etc? -Dean Goodmanson
Darn..that got renderd...lets try it again: !John Doe
<hr>
May'03 - Expanding Wiki Words
??? - upgrade
Jun'03 - Zwiki Freebsd Stability Problems -> Wikilogs Com, Teamflux Com
Jun'03 - Zope Get Slice Bug
Jul'03 - Zope Catalog
Sept'03 - Zwiki Changes200309, Zwiki Cached Links
<hr>
hi, i've set Recent Changes to htmldtml (or rather dtmllinkhtml, i'm on the latest version) and changed <dtml-var src> to <dtml-var src fmt=structured-text>. This makes the whole thing work as expacted by also gives a speed increase.
woops, the tags got eaten by the browser so it's dtml-var src to dtml-var src fmt=structured-text in the Recent Changes source