standard skin tweaks --Simon Michael, Sat, 01 Oct 2005 06:28:09 -0700reply
I believe I'm going to ship the standard skin with the wiki action links
at top right disabled - that is home, changes, contents, discussion,
issues, index. I think most users don't need to see them all on every
page and power-users know they are always accessble via access keys.
That leaves just help, options, subscribe, edit, external edit as you
see on zwiki.org. Also I have tweaked the pagemanagement form's layout.

To make your rss feeds and zwiki.org-style blog listings less junky, do
SomePage?/setupCatalog to add the new isBoring index.

An mailout_policy folder property with value "edits" overrides the
per-user policy (see below), but this may be dropped in a future release.

Changes

Installing

fix __implements__ attribute error when CMF is not installed
(#1149, Warren)
make Zwiki startup more robust with strange locales/strange
pythons (#1158)
make zmi add wiki form use a btreefolder
don't break when adding a wiki with id home (#591)
drop unnecessary loading plugins message at startup
don't log a warning at startup when the system locale is None
clarify missing PTS warning at startup
make fit import failure warning at startup less troubling
fix a case where a page upgrade wouldn't get logged
* don't break when displaying a page whose page type has been
uninstalled

Configuring

wiki subscriber mail-out, rss feeds and blog listings will ignore
boring pages TestPage, SandBox and their offspring, by default.
You can configure different pages in a boring_pages lines folder
property, one per line. An isBoring index has been added to the
standard catalog fields, run /setupCatalog to add it.
* set a true use_double_parenthesis_links property to enable
Wicked-style double parenthesis syntax for freeform wiki links.
This is for world users who can't easily type [].
* rename and delete no longer check for a username in addition to
the permissions (though the skin may still hide them without a
username.)

Browsing

the /changes_rss feed now shows the edit diff
misc_/ image paths are now relative to be more robust with
vhosting (#689)

Editing

be sure to create our own recycle_bin even if the parent folder
has one
purple numbers now disabled by default
allow create to be called directly by page management form

Mail

add "all edits" checkboxes to subscribeform. Zwiki can now send
comments to some, edits to others.
reparent now also sends a mailout
remove (new), add (edit) in mailout subjects for clarity
* just say "links updated" in rename mailout subject

Issue tracking

use more consistent (property change) in issue mailouts, and don't
say it if no property changed
* /issuebrowser was showing filter issues form

General - skins

big skins reorganization to reduce duplication
use a separate createform skin template for creating pages if present
hide most of the wiki action links by default in standard skin
tweak page management form layout in standard skin
drop unnecessary extra text from page management form in cmf/plone
remove old _ and = access keys from /showAccessKeys
register just the zwiki_standard skin with FilesystemSiteDirectory?
when installed
italicise log notes in recent changes
if a |favicon| object is present, set it as the page icon in the
standard skin
don't let recentchanges break when a page type has been uninstalled
use the word "page" instead of "subtopic" in the page management form
don't let non-template objects with the same id hide our skin
templates; improve bad template error
remove the h2 bottom border style
remove stray commas in page templates causing log warnings
drop uploaded and wikinav_portlet templates from plone skin

General

split content/ into wikis/ and scripts/
strip html tags in the page summary, and add renderedSummary which
does formatting and linking
rename all pagetypes' renderXIn methods to format
plugins can now be packages or files
plugins can now override any method in the product core
* add support for emacs-style "hooks" for customization by plugins

I couldn't find anything better than (( )) that is
at most a shift-key away on world keyboards.

Well, except for shift and alt-gr being different keys, what's
the difference between using shift to get brackets or alt-gr?
In both cases you press two keys at the same time. When you have
to type a wikilink with brackets and alt-gr you press 4 keys,
when you use double parentheses then you have to press 6 keys.
Except of course for keyboards that have the numbers and special
characters swapped, like French keyboards.

Well, except for shift and alt-gr being different keys, what's
the difference between using shift to get brackets or alt-gr?
In both cases you press two keys at the same time. When you have
to type a wikilink with brackets and alt-gr you press 4 keys,
when you use double parentheses then you have to press 6 keys.

That is true, though a double press is very little harder than a single
press.

I'm used to typing alt, shift or control with my left hand, while
mousing with the right hand. The idea of using yet another modifier, way
over on the right side, seemed awful. You're right that it's no more
keypresses than shift, but I felt shift is a much more familiar and less
distracting modifier to have to use; we all use it all the time.

Do you all think I was bewitched into adding a feature that adds more
confusion than value ? I'm not 100% sure. It was conceptually a very
easy thing to add (just extend the regexps), though in practice it
required a big cleanup in the linking code (which was valuable).

Well, except for shift and alt-gr being different keys, what's
the difference between using shift to get brackets or alt-gr?
In both cases you press two keys at the same time. When you have
to type a wikilink with brackets and alt-gr you press 4 keys,
when you use double parentheses then you have to press 6 keys.

That is true, though a double press is very little harder than a single
press.

I'm used to typing alt, shift or control with my left hand, while
mousing with the right hand. The idea of using yet another modifier, way
over on the right side, seemed awful. You're right that it's no more
keypresses than shift, but I felt shift is a much more familiar and less
distracting modifier to have to use; we all use it all the time.

Do you all think I was bewitched into adding a feature that adds more
confusion than value ? I'm not 100% sure. It was conceptually a very
easy thing to add (just extend the regexps), though in practice it
required a big cleanup in the linking code (which was valuable).

They're used to that. Even normal US keyboards nowadays have an alt-gr
key, because of the US International layout, where the Euro sign is
alt-gr 5.

one has to use the alt-gr key way over on the right side, seemed

awful.

It's sitting next to the space bar, it's the most central modifier on
the keyboard.

Do you all think I was bewitched into adding a feature that
adds more confusion than value ? I'm not 100% sure.

Well, personally I would like to have it configurable, although I must
admit that that would only add to the confusion. So, let's not go that
way. Instead, a way to turn brackets off would be more useful. I want my
Structured Text footnotes back ;-)

I then tried to create a new issue using the same method, and got the following error:

<snip>
BadRequest: The id "84ThisIsATest2" is invalid - it is already in use.
</snip>

Neither the "84ThisIsATest" or "84ThisIsATest2" issues are viewable within ZWiki, but I can view them in the ZMI, even when I click on the "View" tab. So it appears to be a problem with displaying ZWiki issues and incrementing issue pkey's. I guess ZWiki is creaing issues, but it doesn't recognize them as issues?

Odd Issue Tracker Behavior --TomPurl, Tue, 04 Oct 2005 08:25:18 -0700reply
It looks like I'm having the same problem with ZWiki 0.44 (my previous working version) and Zope 2.8.1. Do anyone know if I have to update something when making the jump from Zope 2.7 to Zope 2.8?

Thanks again!

Odd Issue Tracker Behavior --TomPurl, Tue, 04 Oct 2005 08:53:36 -0700reply
Whoops. Fixed the problem. I should've read the Zope 2.8 Overview before I upgraded Zope. Turns out that I needed to upgrade my ZCatalog instance in ZWiki using the manage_convertIndexes method. Now the issue tracker works very well. That's what I get for a) not reading the readme and b) trying to upgrade Zope and its products at the same time.

So, the first check looks at here, while the second looks at
container. This is an inconsistency.

Furthermore, this particular wiki resides in a subfolder called "wiki"
in the Plone site. I would expect that when I set the "Zwiki: Add pages"
permission on the "wiki" folder, all portal members can add wiki pages
in that folder. They can when they create them through wikilinks, but
the button only shows up when I set the permission one level up, on the
Plone site. This makes me think that container in wikipage.pt should
have been here. Am I right?

It's really clear to me what a fine basis ZWiki could be for a web site
managed by a group of people, BUT I don't want the front door left open.
I'm am amateur, and I just don't know the answer to this question: Is
there some fairly easy way to wrap a ZWiki wiki in a barrier requiring a
password to get past? I don't know of an example of this, but I hope it's
possible. Is it?

___page order insists on alphabetizing

I'm puzzled greatly to see that after taking some real time to get my
pages in the order I wanted they are now appearing in the subtopics list
and in wiki contents listing with all the children of Frontpage
alphabetized - and that the undesired alphabetization goes no further than
that. That's NOT what I was trying to achieve.

2 questions --Tom Cloyd, Tue, 04 Oct 2005 22:34:58 -0700reply
Uh...sorry about the "web site" question. I see the "membership"
discussion in the Admin page at zwiki.org, now. I'm a refugee from Plone,
have had that thing break on my one too many times, but if it only ran a
ZWiki, period, I could probably trust it. I'd rather do something simpler,
but I don't understand any of the other solutions offered in the
discussion, and after 18 months wrestling with Plone I can live with it, I
guess.

As for the page order problem, I upgraded to 0-46-0, and the problem is
solved.

-t.

On Tue, 04 Oct 2005 21:43:46 -0700, Tom Cloyd wrote:

I'm doing a LOT of ZWiki work these days. A couple of questions have come
up.

It's really clear to me what a fine basis ZWiki could be for a web site
managed by a group of people, BUT I don't want the front door left open.
I'm am amateur, and I just don't know the answer to this question: Is
there some fairly easy way to wrap a ZWiki wiki in a barrier requiring a
password to get past? I don't know of an example of this, but I hope it's
possible. Is it?

___page order insists on alphabetizing

I'm puzzled greatly to see that after taking some real time to get my
pages in the order I wanted they are now appearing in the subtopics list
and in wiki contents listing with all the children of Frontpage
alphabetized - and that the undesired alphabetization goes no further
than
that. That's NOT what I was trying to achieve.

Someday, it would be nice if the HTML editor could grow a
"wiki link" command that took the selected text and
constructed the URL from it. :) So, for example, if the
user selects text "Foo Bar", and then clicks on a wiki
link icon, a relative URL of something like "FooBar?" would
be used. I don't know if Epoz is extensible this way.
I suspect Kupu is, but I don't really know.

Having updated both Zopes where I run ZWiki to 0-46-0, I notice two things:

the Alt + i access key does not work (I've never tried it before, so
I've never seen exactly what it does). Do I have to enable something
somewhere to get this functionality?

the link list at the extreme top-right of every page no longer contains
"contents" or "changes". I miss them both, and I think omitting "contents"
is likely a mistake - it's our substitute for a navigation link sidebar
column, and I find it extremely useful. I was just in the process of
educating my users about it when the link dropped out of sight!
Fortunately the access key for this page still works, but they probably
won't be able to remember that.

So... is there any way I can get back at least the "contents" link, or is
it history?

* the Alt + i access key does not work (I've never tried it before, so
I've never seen exactly what it does). Do I have to enable something
somewhere to get this functionality?

It goes to the "index", if it exists - a page named AllPages. I've only
seen this used on zwiki.org.

* the link list at the extreme top-right of every page no longer contains
"contents" or "changes". I miss them both, and I think omitting "contents"
is likely a mistake

You may be right. I felt the same way in the past. Here's my recent
announcement/RFC for this:

Simon Michael wrote:

I believe I'm going to ship the standard skin with the wiki action links
at top right disabled - that is home, changes, contents, discussion,
issues, index. I think most users don't need to see them all on every
page and power-users know they are always accessble via access keys.
That leaves just help, options, subscribe, edit, external edit as you
see on zwiki.org. Also I have tweaked the pagemanagement form's layout.

So... is there any way I can get back at least the "contents" link, or is it history?

If you're willing to customize your wikipage template
(http://zwiki.org/CustomizingAppearance), you can bring them back by
finding the html for those links and changing tal:condition="python:0"
to tal:condition="python:1".

* the Alt + i access key does not work (I've never tried it before, so
I've never seen exactly what it does). Do I have to enable something
somewhere to get this functionality?

It goes to the "index", if it exists - a page named AllPages. I've only
seen this used on zwiki.org.

"Used"? I'm not sure what this means. I can't use it at all, since it
doesn't work. How does it get made functional? Do I create a page named
AllPages, and if so does it get automatically filled with something?

* the link list at the extreme top-right of every page no longer
contains
"contents" or "changes". I miss them both, and I think omitting
"contents"
is likely a mistake

You may be right. I felt the same way in the past. Here's my recent
announcement/RFC for this:

Simon Michael wrote:

You may be right. I felt the same way in the past. Here's my recent
announcement/RFC for this:

Simon Michael wrote:
> I believe I'm going to ship the standard skin with the wiki action links
> at top right disabled - that is home, changes, contents, discussion,
> issues, index. I think most users don't need to see them all on every
page and power-users know they are always accessble via access keys.

I'd be the very first to applaud ZWiki for its superb balance between
power and simplicity! It'd be nice for display of the "contents" link to
be an option, due to its great utility.

How does it get made functional? Do I create a page named
AllPages, and if so does it get automatically filled with something?

Create a page named AllPages, content doesn't matter, and the index link
will appear - in Zwiki versions up to 0.45. In 0.46, the link is
disabled and you have to customize the wikipage template to re-enable
it, in the same way as the other links.

It'd be nice for display of the "contents" link to
be an option, due to its great utility.

It is; I left it in the wikipage template, ready to be reenabled by
changing 0 to 1. This is easy for wiki admins who get into customizing
the skin. I think you're asking for it to be easier than this. Working
against this, there's a point of diminishing returns where it's not
worth the added complexity of a new folder property, a new user option
or whatever. I'd rather figure out a good default that's reasonable for
most sites and make sure there's sufficient documentation for the people
who need to change it.

The current setup favours the idea that most people who find their way
to a random zwiki page care only about the immediate page, do not care
about most of those links at top right, and in fact find them confusing.
"Ugh, random links, it's one of those wiki things". Less is more.

An opposite scenario is that a user coming to a page sees the links and
goes "aha, there is a way to see this wiki's contents, and the changes
(but wiki's or page's ?), and here's how to go home, and there's some
issues in this wiki, good to know, perhaps I'll click one of these to
see more." But this all requires a certain familiarity with wikis and
Zwiki in particular.

So 0.46 drops some hand-holding for the people who (a) aren't afraid of
or confused by zwiki's wiki action links and (b) don't know about access
keys yet; in favour of less clutter and confusion for the people who
know nothing about wikis, and the people who are expert with zwiki.

How does that sound ?

"index" access key not working in 0-46-0 --Simon Michael, Wed, 05 Oct 2005 16:06:08 -0700reply
PS important to note that if the links are not shown at top right, it's
assumed they will be made easy discover on the wiki's front page, and
via the help link as well.

I certainly think this is all well thought out, and is not any kind of
major problem. I can surely live with it. I'm just telling my users
"...and here's something else nice you can do with access keys..." Them
what care will "get it", and thats good enough, I think.

Thanks for your time and thoughts.

t.

On Wed, 05 Oct 2005 16:02:07 -0700, Simon Michael wrote:

Tom Cloyd wrote:

How does it get made functional? Do I create a page named
AllPages, and if so does it get automatically filled with something?

Create a page named AllPages, content doesn't matter, and the index link
will appear - in Zwiki versions up to 0.45. In 0.46, the link is
disabled and you have to customize the wikipage template to re-enable
it, in the same way as the other links.

It'd be nice for display of the "contents" link to
be an option, due to its great utility.

It is; I left it in the wikipage template, ready to be reenabled by
changing 0 to 1. This is easy for wiki admins who get into customizing
the skin. I think you're asking for it to be easier than this. Working
against this, there's a point of diminishing returns where it's not
worth the added complexity of a new folder property, a new user option
or whatever. I'd rather figure out a good default that's reasonable for
most sites and make sure there's sufficient documentation for the people
who need to change it.

The current setup favours the idea that most people who find their way
to a random zwiki page care only about the immediate page, do not care
about most of those links at top right, and in fact find them confusing.
"Ugh, random links, it's one of those wiki things". Less is more.

An opposite scenario is that a user coming to a page sees the links and
goes "aha, there is a way to see this wiki's contents, and the changes
(but wiki's or page's ?), and here's how to go home, and there's some
issues in this wiki, good to know, perhaps I'll click one of these to
see more." But this all requires a certain familiarity with wikis and
Zwiki in particular.

So 0.46 drops some hand-holding for the people who (a) aren't afraid of
or confused by zwiki's wiki action links and (b) don't know about access
keys yet; in favour of less clutter and confusion for the people who
know nothing about wikis, and the people who are expert with zwiki.

"index" access key not working in 0-46-0 --Tom Cloyd, Wed, 05 Oct 2005 23:24:25 -0700reply
Tom, thanks. I'd appreciate that. I'm not intimidated at all by HTML, but
I'm maxed out right now on things-to-learn, so if something new's not
quick and simple and rather bullet proof, I have to pass for the time
being.

I look forward to hearing from you.

tc@bestmindhealth.com

Tom C.

On Wed, 05 Oct 2005 18:12:53 -0700, Tom Purl wrote:

On Wed, Oct 05, 2005 at 04:16:04PM -0700, Tom Cloyd wrote:

I certainly think this is all well thought out, and is not any kind of
major problem. I can surely live with it.

Tom, I made this change today to my 0.46 ZWiki instance. I can
understand how CustomizingAppearance instructions can be a little
daunting if you're not used to editing HTML.

If you'd like, I can e-mail my version of wikipage.pt to you, and you
can add it to the root of your ZWiki instance as a "page template" with
a id of "wikipage". This will fix your problem.

page recovery tip --Simon Michael, Thu, 06 Oct 2005 14:07:16 -0700reply
Issue 637 was overwritten by some junk and strangely I couldn't see the
old text in the diffs or zmi history views. Though I did see most of it
in the mail-out; so that's strange.

I looked for it first on archive.org, didn't find it. Google had it
cached. By searching for the page id
(637FileUploadShouldCreatePortalFilesInCMFPlone) I was able to see how
the page looked, and by searching for
637FileUploadShouldCreatePortalFilesInCMFPlone/src and then doing view
source I could get the exact source text for pasting into the page.

anonymous link posting restricted --Simon Michael, Thu, 06 Oct 2005 18:59:41 -0700reply
A one-link spammer has found zwiki.org. I've reduced the
max_anonymous_links from 1 to 0, for a while at least. Unfortunately
this means that an unidentified anonymous visitor can no longer post
even one external link.

The size of the RST Primary and Secondary level headings (and probably
other levels as well) are VERY different between the two systems. They
look almost too large on the WinXP? box, but on the FreeBSD?, the Secondary
level is really a bit small.

I'm baffled by all this (hey, it doesn't take much!). The ZWiki's are the
same. I suspect that the Zope's are almost the same - in both cases I'm
the using the Zope that loads with the most-current version of Plone for
each OS. In Windows, the Zope is just labeled something like "unreleased
version".

I can live with the crazy difference between the browsers, but what's with
the refusal to accept a standard RST convention for a

? I actually
do need to insert some lines in some documents, so this is a definite
inconvenience.

HTML to RSTx?? --Tom Cloyd, Fri, 07 Oct 2005 03:24:31 -0700reply
Is there any reasonably easy way to put HTMLized? content into a page, and
get it out as RSTx?? I could use this functionality. Or maybe it's
available in some Docutils routine that could be run stand-alone?

That completely changes the editing experience my very ignorant
can't-won't-learn-anything-new-like-RST hyper-educated therapist users
might have. Heck, it looks like a little word processor - they might be
able to use it! (I've actually used Epoz for some time, but dislike it
intensely, as it mangles my HTML, blows up my comments, and generally
pisses me off 'cause of the archaic HTML it generates. Aragh I hate that
thing. But...it has its uses.

That said...is anything new on the horizon for ZWiki-in-Zope without
Plone? Kupu maybe? Dare I hope?

I've been wanting to add a link to the immediate ancestor for each summary on the blog page, and I was happy to see that the ZopeWiki:WebLog page already had a "Created In" link. I therefore took a look at the DTML and found the following snippet:

Every line of DTML above works well except for line 3. The error message that I'm getting isn't descriptive, unfortunately. I tried the following instead and didn't get an error:

<dtml-var p_item>

When I do this, I can see the immediate ancestor, but there isn't a link to it.

Can anyone see why line 3 is bombing for me? I'm using ZWiki 0.46 + Zope 2.8.1. Any help at all would be greatly appreciated!

Adding a "Created In" Section To The Blog Interface --tom, Wed, 12 Oct 2005 12:00:08 -0700reply
Sorry guys, that was awfully dense on my part. I just took a look at the
stack trace again and finally found the error:

KeyError: 'wikiurl'

I then looked at my page, and apparently wikurl needs to be wikiUrl.
That fixed my problem.

Sorry to clutter-up the GeneralDissucssion? page. I'm still getting used
to debuggin DTML.

you'll see more details of such errors in the error log,
http://zopewiki.org/error_log . I usually forward these to the event log
and leave that running in a window (tail -f event.log) when working with
dtml.

I think wikiurl is wrong. It may have been wiki_url in the past, these
days it's wikiUrl.

Note parents are page names, and could have spaces, punctuation,
non-ascii characters etc. If you have FuzzyUrls set up, the links will
probably work for you anyway. A more robust way would be something like
this:

That will touch each page object, forcing it to be loaded into the zodb
cache, though. For most sites this will not have any noticeable impact.
If you had to display a lot of these and were concerned about avoid zodb
cache loads, you could do instead:

Calling A Utils.py Method From A Wiki TestPage --TomPurl, Wed, 19 Oct 2005 13:45:48 -0700reply
Hi, I'm trying to create a new method in the Utils.py script that returns all of the "tags" that are listed in a wiki page. Basically, I want to be able to put something like the following line in some of my wiki pages:

Tags: TestTag1, TestTagN

I wrote a simple method in Utils.py that parses the content of a wiki page for the line listed above and then returns a list of tag names. I can call this method from the root of my wiki instance in a "Script (Python)" object using the following code:

page = container.SomePageWithTags
print page.getTags()
return printed

My method works when I invoke it this way. The problem is that when I try and do something similar with DTML, I get no output. Here's the DTML that I'm using:

<dtml-in getTags prefix=t>
<dtml-var t_item>
</dtml-in>

I also tried the following DTML:

<dtml-in getTags>
<dtml-var sequence-item>
</dtml-in>

At first I thought that this might be a security issue since I was executing the Script (Python) object as the "root" Zope user, and I was trying to view the DTML page as an anonymous user, but my results didn't change when I authenticated as the "root" Zope user.

Can anyone see what the missing link is between my DTML and the Utils.py method?

Moving a Zwiki --Mark Beazer, Fri, 21 Oct 2005 07:49:35 -0700reply
Hi. I'm a ZWiki newbie, I hope this is the right place for questions.
I have a ZWiki on computer A, which I'd like to move to computer B, which also has ZWiki installed. What is the best way to move it? (And I'm hoping the answer isn't "one page at a time" :))

I have been playing around with the same setup as you described on htmlonly.demo.zwiki.org and quickly found two showstopper issues (Problems with setting parents for new pages and problems with double-byte characters in title. further details: see there). Is it possible to solve these issues easily either with a workaround or a quick change/hack, or further development is needed? I just would like to know whether it's worth considering for my demonstration purposes or not. Thanks in advance,
József

oopsla, time --Simon Michael, Wed, 26 Oct 2005 09:02:43 -0700reply
I'm still here.. thanks for the recent patches and bug reports, which
I'll get to asap (my way of forwarding patches to the repo seems to have
broken..)

OOPSLA/Wikisym was terrific. I met a lot of interesting people,
including Ward C who gave a great talk about the anti-spam steward tools
at WikiWikiWeb, and got energised and stimulated.

I didn't do any demo or speaking about Zwiki; I had my hands full just
figuring out what to do and where to go in this huge conference. In fact
I didn't really get to hang out a lot at wikisym, because in truth I was
more interested in the all-day squeak croquet workshop which was on the
other side of the campus.

One high point: together with Lex Spoon and Adam and Alex (who work on
Klein, which is Self implemented in itself), I was there when David
Smith and Andreas Raab fixed the bug that allowed them to run the real
TeaTime? for the first time, and bought them a celebratory beer. Hurrah!
At this conference I got a big boost for continued squeak and croquet
work; it's really exciting stuff. I also bought philikon's zope 3 book
and got a big boost there too.

Since, I have been experimenting with a new "one focus per day"
discipline. Today was to be the day for zwiki and squeak. But as so
often happens, my client's project seems to just eat time; the days I've
spent have not produced enough progress that I feel ok leaving it for
even a day.

I think this heavily ttw-customized, rdbms-integrated, multi-product
plone 2.0 site just exceeds my available brain space at this point. If
this were the only focus I could still handle it, but it's just the
current priority among many. I've got to simplify this thing and get out
of this mess so I can feel productive again. Also, I need a pair
programmer. I put out the call last night.