diff options
Diffstat (limited to 'doc/todo')
| -rw-r--r-- | doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 | ||||
| -rw-r--r-- | doc/todo/autoindex_should_use_add__95__autofile.mdwn | 110 | ||||
| -rw-r--r-- | doc/todo/feed_enhancements_for_inline_pages.mdwn | 8 | ||||
| -rw-r--r-- | doc/todo/generic_insert_links.mdwn (renamed from doc/todo/generic_insert_links) | 0 | ||||
| -rw-r--r-- | doc/todo/support_includes_in_setup_files.mdwn | 10 | ||||
| -rw-r--r-- | doc/todo/transient_pages.mdwn | 117 | ||||
| -rw-r--r-- | doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn | 45 |
7 files changed, 258 insertions, 37 deletions
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 16dc78fb2..da0389261 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -260,7 +260,10 @@ required to implement [[todo/alias directive]], which couldn't be easily done by writing to the RCS as the page's contents can change depending on which other pages claim it as an alias. --[[chrysn]] -I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. -- +I agree with [[chrysn]]. In fact, is there any good reason that the core tag +plugin doesn't do this? The current usability is horrible, to the point that +I have gone 2.5 years with Ikiwiki and haven't yet started using tags. +--[Eric](http://wiki.pdxhub.org/people/eric) > See [[todo/transient_pages]] for progress on this. --[[smcv]] diff --git a/doc/todo/autoindex_should_use_add__95__autofile.mdwn b/doc/todo/autoindex_should_use_add__95__autofile.mdwn index 19c5004f8..9f3fd71f1 100644 --- a/doc/todo/autoindex_should_use_add__95__autofile.mdwn +++ b/doc/todo/autoindex_should_use_add__95__autofile.mdwn @@ -1,4 +1,112 @@ `add_autofile` is a generic version of [[plugins/autoindex]]'s code, so the latter should probably use the former. --[[smcv]] -> See [[todo/transient_pages]] for progress on this. --[[smcv]] +---- + +[[!template id=gitbranch branch=smcv/autoindex-autofile author="[[smcv]]"]] + +I'm having trouble fixing this: + + # FIXME: some of this is probably redundant with add_autofile now, and + # the rest should perhaps be added to the autofile machinery + +By "a generic version of" above, it seems I mean "almost, but not +quite, entirely unlike". + +> As long as it's not Tea. ;) --[[Joey]] + +I tried digging through the git history for the +reasoning behind the autofile and autoindex implementations, but now I'm +mostly confused. + +## autofile + +The autofile machinery records a list of every file that has ever been proposed +as an autofile: for instance, the tag plugin has a list of every tag that +has ever been named in a \[[!tag]] or \[[!taglink]], even if no file was +actually needed (e.g. because it already existed). Checks for files that +already exist (or whatever) are deferred until after this list has been +updated, and files in this list are never auto-created again unless the wiki +is rebuilt. + +This avoids re-creating the tag `create-del` in this situation, which is +the third one that I noted on +[[todo/auto-create tag pages according to a template]]: + +* create tags/create-del manually +* tag a page as create-del +* delete tags/create-del + +and also avoids re-creating `auto-del` in this similar situation (which I +think is probably the most important one to get right): + +* tag a page as auto-del, which is created automatically +* delete tags/auto-del + +I think both of these are desirable. + +However, this infrastructure also results in the tag page not being +re-created in either of these situations (the first and second that I noted +on the other page): + +* tag a page as auto-del-create-del, which is created automatically +* delete tags/auto-del-create-del +* create tags/auto-del-create-del manually +* delete tags/auto-del-create-del again + +or + +* create tags/create-del-auto +* delete tags/create-del-auto +* tag a page as create-del-auto + +I'm less sure that these shouldn't create the tag page: we deleted the +manually-created version, but that doesn't necessarily mean we don't want +*something* to exist. + +> That could be argued, but it's a very DWIM thing. Probably best to keep +> the behavior simple and predictable, so one only needs to remember that +> when a page is deleted, nothing will ever re-create it behind ones back. +> --[[Joey]] + +## autoindex + +The autoindex machinery records a more complex set. Items are added to the +set when they are deleted, but would otherwise have been added as an autoindex +(don't exist, do have children (by which I mean subpages or attachments), +and are a directory in the srcdir). They're removed if this particular run +wouldn't have added them as an autoindex (they exist, or don't have children). + +Here's what happens in situations mirroring those above. + +The "create-del" case still doesn't create the page: + +* create create-del manually +* create create-del/child +* delete create-del +* it's added to `%deleted` and not re-created + +Neither does the "auto-del" case: + +* create auto-del/child, resulting in auto-del being created automatically +* delete auto-del +* it's added to `%deleted` and not re-created + +However, unlike the generic autofile infrastructure, `autoindex` forgets +that it shouldn't re-create the deleted page in the latter two situations: + +* create auto-del-create-del/child, resulting in auto-del-create-del being + created automatically +* delete auto-del-create-del; it's added to `%deleted` and not re-created +* create auto-del-create-del manually; it's removed from `%deleted` +* delete auto-del-create-del again (it's re-created) + +and + +* create create-del-auto +* delete create-del-auto; it's not added to `%deleted` because there's no + child that would cause it to exist +* create create-del-auto/child + +> I doubt there is any good reason for this behavior. These are probably +> bugs. --[[Joey]] diff --git a/doc/todo/feed_enhancements_for_inline_pages.mdwn b/doc/todo/feed_enhancements_for_inline_pages.mdwn new file mode 100644 index 000000000..5a7b1f839 --- /dev/null +++ b/doc/todo/feed_enhancements_for_inline_pages.mdwn @@ -0,0 +1,8 @@ +[[!template id=gitbranch branch=GiuseppeBilotta/inlinestuff author="Giuseppe Bilotta"]] + +A few patches to clean up and improve feed management for inline pages. + +* the first patch simply replaces the id attribute in the default template for feedlinks with a class attribute by the same name. This is necessary in pages with multiple inlines to guarantee correctness +* the second patch tries to define the default description for a feed based not only on the wiki name, but also on the current page name. The actual way this is built might not be the optimal one, so I'm open to suggestions +* the third patch passes the feed titles to the templates, changing the default templates to use these as title attributes for the links. a rel="alternate" attribute is also included +* the fourth patch introduces a feedlinks parameter to the inline directive, to allow for the specifications of the locations where the feed links should appear. Currently, two options are allowed (head and body), plus both and none with obvious significance diff --git a/doc/todo/generic_insert_links b/doc/todo/generic_insert_links.mdwn index 050f32ee7..050f32ee7 100644 --- a/doc/todo/generic_insert_links +++ b/doc/todo/generic_insert_links.mdwn diff --git a/doc/todo/support_includes_in_setup_files.mdwn b/doc/todo/support_includes_in_setup_files.mdwn new file mode 100644 index 000000000..50afb2b6b --- /dev/null +++ b/doc/todo/support_includes_in_setup_files.mdwn @@ -0,0 +1,10 @@ +I have a client server setup so I can I edit/preview on my laptop/desktop and push to a server. I therefore have two almost identical setup files that reasonably often I let get out of sync. I'd like to be able into include the common parts into the two setup files. Currently the following works, but it relies on knowing the implementation of IkiWiki::Setup::Standard + +use IkiWiki::Setup::Standard { specific stuff }; +require "/path/to/common_setup"; + +where common_setup contains a call to IkiWiki::Setup::merge + +To see that this is fragile, note that the require must come second, or ikiwiki will try to load a module called IkiWiki::Setup::merge + +DavidBremner diff --git a/doc/todo/transient_pages.mdwn b/doc/todo/transient_pages.mdwn index 911f208fd..1a35dddb1 100644 --- a/doc/todo/transient_pages.mdwn +++ b/doc/todo/transient_pages.mdwn @@ -22,6 +22,8 @@ It could also be used for an [[todo/alias_directive]]. -------------------------- [[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]] +[[!template id=gitbranch branch=smcv/ready/transient-recentchanges author="[[smcv]]"]] +[[!template id=gitbranch branch=smcv/ready/transient-tag author="[[smcv]]"]] [[!tag patch]] I think this branch is now enough to be useful. It adds the following: @@ -31,17 +33,21 @@ as an underlay. I'm not sure whether this should be a plugin or core, so I erred on the side of more plugins; I think it's "on the edge of the core", like goto. -Pages with the default extension in the transient underlay are automatically +Pages in the transient underlay are automatically deleted if a page of the same name is created in the srcdir (or an underlay closer to the srcdir in stacking order). +With the additional `ready/transient-tag` branch, `tag` enables `transient`, and if `tag_autocreate_commit` is set to 0 (default 1), autocreated tags are written to the transient underlay. There is a regression test. +With the additional `transient-autoindex` branch, `autoindex` uses autofiles. It also enables `transient`, and if `autoindex_commit` is set to 0 (default 1), autoindexes are written to -the transient underlay. There is a regression test. +the transient underlay. There is a regression test. However, this branch +is blocked by working out what the desired behaviour is, on +[[todo/autoindex_should_use_add__95__autofile]]. > I wonder why this needs to be configurable? I suppose that gets back to > whether it makes sense to check these files in or not. The benefits of @@ -64,15 +70,25 @@ the transient underlay. There is a regression test. > commit clutter is really worth it. >> According to the last section of ->> [[todo/auto-create_tag_pages_according_to_a_template]], chrysn and +>> [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]] and >> Eric both feel rather strongly that it should be possible to ->> not commit any tags. I made it configurable because, as you point out, +>> not commit any tags; in [[plugins/autoindex/discussion]], +>> lollipopman and [[JoeRayhawk]] both requested the same for autoindex. +>> I made it configurable because, as you point out, >> there are also reasons why it makes sense to check these >> automatically-created files in. I'm neutral on this, personally. >> >> If this is a point of contention, would you accept a branch that >> just adds `transient` and uses it for [[plugins/recentchanges]], ->> which aren't checked in and never have been? +>> which aren't checked in and never have been? I've split the +>> branch up in the hope that *some* of it can get merged. +>> +>>> I will be happy to merge transient-recentchanges when it's ready. +>>> I see no obstacle to merging transient-tag either, and am not +>>> really against using it for autoindex or aggregate either +>>> once they get completed. +>>> I just wanted to think through why configurability is needed. +>>> --[[Joey]] >> >> One potentially relevant point is that configuration clutter only >> affects the site admin whereas commit clutter is part of the whole @@ -80,18 +96,31 @@ the transient underlay. There is a regression test. > Anyway, the configurability > appears subtly broken; the default is only 1 if a new setup file is -> generated. With an existing setup file, the 'default' values in +> generated. (Correction: It was not even the default then --[[Joey]]) +> With an existing setup file, the 'default' values in > `getsetup` don't take effect, so it will default to undef, which > is treated the same as 0. --[[Joey]] ->> Fixed in the branch, hopefully. (How disruptive would it be to have +>> Fixed in the branches, hopefully. (How disruptive would it be to have >> defaults take effect whenever the setup file doesn't set a value, btw? >> It seems pretty astonishing to have them work as they do at the moment.) --s +>>> Well, note that default is not actually a documented field in +>>> getsetup hooks at all! (It is used in IkiWiki.pm's own `getsetup()`, and +>>> the concept may have leaked out into one or two plugins (comments, +>>> transient)). +>>> +>>> Running getsetup at plugin load time is something I have considered +>>> doing. It would simplify some checkconfig hooks that just set hardcoded +>>> defaults. Although since dying is part of the getsetup hook's API, it +>>> could be problimaric. +>>> --[[Joey]] + autoindex ignores pages in the transient underlay when deciding whether to generate an index. -New recent changes go in the transient underlay; I tested this manually. +With the additional `ready/transient-recentchanges` branch, new recent +changes go in the transient underlay; I tested this manually. Not done yet (in that branch, at least): @@ -125,48 +154,68 @@ Not done yet (in that branch, at least): >> Here are some other things I'd like to think about first: --[[Joey]] >> >> * There's a FIXME in autoindex. - ->>> Right, the extra logic for preventing autoindex pages from being ->>> re-created. I've started on regression tests for this, but I'll ->>> need to rummage through the commit log for the exact requirements ->>> and the reasoning behind them, so it could take a while. --s +>> +>> > Right, the extra logic for preventing autoindex pages from being +>> > re-created. This is taking a while, so I'm going to leave out the +>> > autoindex part for the moment. The FIXME is only relevant +>> > because I tried to solve +>> > [[todo/autoindex should use add__95__autofile]] first, but +>> > strictly speaking, that's an orthogonal change. --s >> * Suggest making recentchanges unlink the transient page >> first, and only unlink from the old location if it wasn't >> in the transient location. Ok, it only saves 1 syscall :) +>> +>> > Is an unlink() really that expensive? But, OK, fixed in the +>> > `ready/transient-recentchanges` branch. --s ->>> Is an unlink() really that expensive? But, OK, fixed in the ->>> updated branch. --s +>> >> It's not, but it's easy. :) --[[Joey]] >> * Similarly it's a bit worrying for performance that it >> needs to pull in and use `Cwd` on every ikiwiki startup now. >> I really don't see the need; `wikistatedir` should >> mostly be absolute, and ikiwiki should not chdir in ways >> that break it anyway. - ->>> The reason to make it absolute is that relative underlays ->>> are interpreted as relative to the base underlay directory, ->>> not the cwd. ->>> ->>> The updated branch only loads `Cwd` if the path is relative; ->>> an extra commit on branch `smcv/transient-relative` goes ->>> behind `add_underlay`'s back to allow use of a cwd-relative ->>> underlay. Which direction would you prefer? --s +>> +>> > The reason to make it absolute is that relative underlays +>> > are interpreted as relative to the base underlay directory, +>> > not the cwd, by `add_underlay`. +>> > +>> > The updated `ready/transient-only` branch only loads `Cwd` if +>> > the path is relative; an extra commit on branch +>> > `smcv/transient-relative` goes behind `add_underlay`'s +>> > back to allow use of a cwd-relative underlay. Which direction +>> > would you prefer? +>> > +>> > I note in passing that [[plugins/autoindex]] and `IkiWiki::Render` +>> > both need to use `Cwd` and `File::Find` on every refresh, so +>> > there's only any point in avoiding `Cwd` for runs that don't +>> > actually refresh, like simple uses of the CGI. --s + +>> >> Oh, right, I'd forgotten about the horrificness of File::Find +>> >> that required a chdir for security. Ugh. Can we just avoid +>> >> it for those simple cases then? (demand-calculate wikistatedir) +>> >> --[[Joey]] >> * Unsure about the use of `default_pageext` in the `change` >> hook. Is everything in the transientdir really going >> to use that pageext? Would it be better to look up the >> complete source filename? - ->>> At the moment everything in the transientdir will either ->>> have the `default_pageext` or be internal, although I ->>> did wonder whether to make [[plugins/contrib/album]] ->>> viewer pages optionally be `html`, for better performance ->>> when there's a very large number of photos. ->>> ->>> A more thorough garbage-collection mechanism would be to ->>> use File::Find on the transient directory; I'll get there ->>> eventually. --s +>> +>> > I've updated `ready/transient` to do a more thorough GC by +>> > using File::Find on the transient directory. This does +>> > require `File::Find` and `Cwd`, but only when pages change, +>> > and `refresh` loads both of those in that situation anyway. +>> > +>> > At the moment everything in the transientdir will either +>> > have the `default_pageext` or be internal, although I +>> > did wonder whether to make [[plugins/contrib/album]] +>> > viewer pages optionally be `html`, for better performance +>> > when there's a very large number of photos. --s + +>> >> Oh, ugh, more File::Find... Couldn't it just assume that the +>> >> transient page has the same extension as its replacement? +>> >> --[[Joey]] -------------------------- diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index b069ee2bd..6ede7f91e 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -1,3 +1,46 @@ +## current status + +[[done]] again! :) + +Actually, there are two places where the configured url is still hardcoded: + +1. When searching, all the links will use it. This is annoying to fix, + and we deem it not a problem. +2. When ikiwiki dies with an error, the links on the error page will + use it. Too bad :) + +------ + +## semi-old + + +* CGI pages, with the exception of edit pages, set `<base>` to + `$config{url}` + + I had to revert using `baseurl(undef)` for that, because it needs + to be a full url. + + Ideally, baseurl would return an absolute url derived from the url + being used to access the cgi, but that needs access to the CGI object, + which it does not currently have. Similarly, `misctemplate` + does not have access to the CGI object, so it cannot use it to + generate a better baseurl. Not sure yet what to do; may have to thread + a cgi parameter through all the calls to misctemplate. --[[Joey]] + + > Fixed, cgitemplate is used now. --[[Joey]] + +* Using `do=goto` to go to a comment or recentchanges item + will redirect to the `$config{url}`-based url, since the + permalinks are made to be absolute urls now. + + Fixing this would seem to involve making meta force permalinks + to absolute urls when fulling out templates, while allowing them + to be left as partial urls internally, for use by goto. --[[Joey]] + + > This reversion has now been fixed. --[[Joey]] + +## old attempt + It looks like all links in websites are absolute paths, this has some limitations: * If connecting to website via https://... all links will take you back to http:// @@ -320,7 +363,7 @@ Potential future things: >> and 5 in plugins, since I used it for things like redirection back >> to the top of the wiki --[[smcv]] -[[merged|done]] --[[Joey]] +merged|done --[[Joey]] (But reopened, see above.) ---- |