Technically, when the user does this, a passwordless account is created
for them. The notify mails include a login url, and once logged in that
way, the user can enter a password to get a regular account (although
one with an annoying username).
This all requires the passwordauth plugin is enabled. A future enhancement
could be to split the passwordless user concept out into a separate plugin.
This allows per-form/feedlink group customization without having to
resort to counting.
(cherry picked from commit b134feb0dc2d9a8ff7ae447537fa8bc02811aabd)
There can be more than one feedlink group in a page, as well as (more
rarely) multiple blog forms, and using the same id for all of them
causes HTML validation errors. Replace the id with a class by the same
name and adjust in-repository CSS.
(cherry picked from commit 0c3b91e1f06fb357711cfa71d514f139cd8e04e3)
The default templates are also updated to make use of this information.
The rel="alternate" attribute is also inserted, for completeness.
(cherry picked from commit 618ade535e6a7967a510d9e210edaef3d37cc9bc)
The rss spec says that unless the attribute is set, guid elements *are*
permalinks. The problem with that is that if [[meta permalink=]] is used,
as is done with aggregated posts, that goes into the link element, and
apparently some rss readers prefer the not-really-permalink in the guid
element when linking to the post.
Without meta permalink, the link and guid elements have the same content,
so it should be ok, in that case too for the guid to not be a permalink.
(Checked and this does not flood aggregators.)
Since misctemplate is called with a page context, the comments plugin
thinks it should add that, as well as the comment link in the actionbar.
I kept the comment link because a quick link back to the comments to a page
is sorta useful.
The styling of labels on the form largely obsoleted the special styled ol,
so just a few br's sufficed. Using an ol like that was not too semantically
right (probably?) and could cause problems with customized local.css.
The key is using width: auto; overflow: auto; -- this allows the div(s) to the
left of the floating sidebar to be resized to fit next to it, and prevents
any clear: both from pushing the div down below the end of the sidebar.
Many thanks for the Hurd wiki's developers for originally figuring this out.
The edit page recently developed the same problem with its textarea, now
that a sidebar can appear on that page too. In editpage.tmpl I needed to
add a new div around the editcontent textarea, as the above styles cannot
be applied directly to textareas. The textarea's own width is reduced to
98% because at least in chromium this avoids it getting unnecessary
horizonatl scrollbars when a sidebar is displayed next to it.
http://bzed.de/posts/2010/05/new_css_for_bzed.de/
smcv: [10:59:01] is the logical thing you want a <div> whose meaning is "the bits the sidebar is allowed to accompany"?
bzed: [10:59:14] yeah
bzed: [10:59:58] then you could just ensure that this part is as high as the sidebar
smcv: [11:02:44] wrapping a <div> around the sidebar, content and comments seems like the way forward, then
Joey Hess
intrigeri
Antoine Beaupré
Simon McVittie
Paul Wise
Francois Marier
Giuseppe Bilotta
Peter Gammie