Click here to edit contents of this page.
Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available.
Append content without editing the whole page source.
Check out how this page has evolved in the past.
If you want to discuss contents of this page - this is the easiest way to do it.
View and manage file attachments for this page.
A few useful tools to manage this Site.
See pages that link to and include this page.
Change the name (also URL address, possibly the category) of the page.
View wiki source for this page without editing.
View/set parent page (used for creating breadcrumbs and structured layout).
Notify administrators if there is objectionable content in this page.
Something does not work as expected? Find out what you can do.
General Wikidot.com documentation and help section.
Wikidot.com Terms of Service - what you can, what you should not etc.
Wikidot.com Privacy Policy.
Just a question: because I don't need it, I'd like to know why 22 people did.
Maybe after I could change my mind and my vote. :)
To expand on why people might want to post date a blog entry, some blogs have an audience that is attuned to receiving information in certain spurts — it varies blog to blog, but some people want to/are accustomed to see(ing) fresh content every afternoon, every morning, every friday, etc, depending on how that blog functions. A blog creator wants to meet these expectations to ensure that their regulars feel well served and keep coming back, while at the same time, they don't want to be tied to posting at exactly these times.
Bloggers need flexibility for all kinds of reasons (vacations, day jobs etc), and postdating allows them to create content in advance, but release it on a schedule that meets the needs of their audience.
It lets you post-date blog entries so that they appear only at a certain date; it also lets you create older blog posts, e.g. if you are moving stuff from another site.
Portfolio
Posdating would allow confortable drafting by setting a date in the near future:
with 2 versions of ListPages
- one for drafting, i.e. not taking into account the to be published date
- one for publishing (public view)
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!
Why double the work with two versions of ListPages? This should be able to be done with a parameter… showFuturePages="false" by default
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Please, noMoreCamelCase :-)
Yes, one version of ListPages with future="yes|no" as an argument.
Portfolio
Hey fools,
please try to read between lines:
I did not mean two versions of the module, of course (I have the black belt, haven't I ?).
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!
Sorry… Java/C++ developer here.. :)
So do I… I'll fight you — see who the real karate champion is! ;-)
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
The vast majority of comments I've seen on this topic, here and elsewhere, focus on setting future dates — with the exception of pieterh's above, I did read it! — so I'm going to add my two cents regarding why setting past dates is also useful:
Say you're transferring something to Wikidot, or otherwise making an archive. While you can create pages in order, assuming you have the complete set of information to begin with, created_at won't match the original date of the information, and it's fairly difficult to store the date in a way that can be accessed in a ListPages module — unless you use a live template and %%content{n}%%, which isn't actually always the most appropriate approach in all contexts, at least in my experience. And if you should happen to upload one out of order… especially if you don't notice until much later, when you'd have to delete many pages in order to fix the created_at sequence… you're out of luck.
You can't order by tags in ListPages, so the info can't be dated and organized through them, and while you can use page name/URL for dating that starts to get cumbersome if you have multiple entries for a single day. Linking back to that page later also requires looking up the URL (because what you probably remember is the descriptive phrase in the page title, or a synopsis of the page content, not the timestamp in its URL).
If you have a collaborative project, with multiple people adding information that gets spliced in together, then any one person doesn't have all of the information to begin with, so they can't just upload all the pages in correct sequence. The more abstracted and higher-resolution the page-naming system is (e.g. 'requiring year-month-day-hour' instead of 'just type the page title in the newpage box'), the less transparent it is to a group, especially if a good percentage of them are typical end-users (who can be incredibly stubborn about not learning even Wikidot syntax!) rather than technically-minded people.
I freely admit that my personal application for this feature is a 'niche' — using it for collaborative archives of roleplay logs, which are often 'creatively dated' (i.e. to yesterday or tomorrow, or even years in the past, or in rare cases in the future) and uploaded out of actual order-of-effect. It would also be useful for me in creating a code archive and setting the created_at of each program's page to the date it was first finished (which in many cases predate the wiki site, because I have several years' worth of code that would go up).
But… I could see being able to set to a past date also being very useful for organizing anything by time — if your site is about the history of some product (games, software versions and releases, postcards, etc.), or a record of events for a place or community, or anything else of that nature — and just like roleplaying, there are at least a fair minority of Wikidot sites that focus on such subjects — you can date each page with the day it happened, and then easily organize them in chronological succession; it's definitely the most intuitive and elegant way to combine that with ListPages.
That was a lovely essay!
Hah, thanks. ;)
Agreed. Great post!!
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
What is setting a past date ?
Each page of a wiki is record of a database1, with fields such as pagename, which are editable and other fields such as creation date or modified date, which are not (yet).
My weneed covered the "past" date set by the user at creation of the page (instead of being set automatically) and of course, the ability to modifiy at wish this past date, as any other meta data, which is weneed:6.
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!
Is this idea scheduled or already being worked on, or is it still only another item on the wishlist/weneed lists? Knowing this would help me to decide how to structure a category of pages on a project of mine.
Thanks.
Sue
The idea is to create your sites for the features that currently exist, and not to rely on those that are planned or being designed.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Yes, this is always the best plan. If you wait for specific features you'll just lose opportunity.
Portfolio
weneed:11 The third most voted for weneed.
It's a fair question that I'm asking. A straight yes or no would suffice, in keeping with your usual no-bullshit style, Pieter. :-)
yes = scheduled or already being worked on
no = only another item on the wishlist/weneed lists
Please allow me to be the judge of how I act upon that information.
Sue
I understand where you're coming from Sue… I feel the same way.
Sue, I too think it is a fair question. And it is one I have raised before here where I suggested a simple traffic light system to give a quick status:
green: assessment and/or development is underway
amber: no assessment or development has started yet
red: assessment or development had started but has stopped for technical or other reasons.
I do think it is important, not least on the roadmap items where people are committing hard cash and should therefore be given some degree of feedback (without that the roadmap risks being just another wishlist). It does not commit Wikidot to any specific timeframe but gives the users a quick idea of what is being assessed or developed. As the weneeds and roadmap issues get longer it would also keep people like me off Pieter's back to an extent which I'm sure he would welcome.
Rats, I told myself I would have a quiet week working on my own sites and not raising contentious issues or annoying anyone, Pieter in particular. I have failed and it's only Monday lunchtime!
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Yes in an ideal world that would be true. My world however seems very flawed and I have several projects underway which, if we are to use Wikidot, need private categories implemented in order for the whole site to be accepted. I am developing them v-e-r-y v-e-r-y s-l-o-w-l-y so I don't have to use TWIki instead of Wikidot.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Let me put it like this: the Wikidot development team is still too small to let me make promises I can keep. We have conflicting demands and keeping the service running fast always beats new features. And bug fixes beat new features. And support beats new features.
So what we are doing is to slowly but surely grow the team, work better, and ramp up the production of useful new code. We are about… 50% of the way there, IMO. You will see a big improvement over 6 months ago but still much to be desired.
Today, any promise or planning on new features would be a lie and I'm not going to do that. Our top priorities for major new features for now (after service and bug fixes) are:
And then more tools along the lines of ListPages.
Page metadata is something I personally really want but it is not scheduled yet. It has more or less been designed, which is already important.
I'd recommend anyone really needing a feature to spend some time looking, or demanding, designs for the feature. We've found that a well-matured design sketch lets us implement very rapidly.
Portfolio
On behalf of Pieter, I would say it's a “no, but you may get this feature done by Christmas next year” ;-)
All uses of this "feature" would be covered by proper data form, when we have date fields and ability to select and order based on that.
Piotr Gabryjeluk
visit my blog
This is not the same as setting page meta data.
Portfolio
So, you simply rejected a wish that collected 33 votes and you didn't say why.
gerdami - Visit Handbook en Français - Rate this howto:import-simple-excel-tables-into-wikidot up!
This is the explanation.
More detailed one: we want to supply a reliable created_at property. If you want to "set" dates of "creation", you usually mean "set date of publish", which can be nicely done by a proper form field saying "publish date" and a selector for ListPages saying … from_data{published_at}="<NOW" or something like this. Whatever the syntax will be, this is the solution we want to head on, instead of messing with reliable properties of pages.
Piotr Gabryjeluk
visit my blog
in what sense does this proposal make the wish 'rejected'? Surely this means 'accepted' and you are here explaining how you intend to make it?
Portfolio
It's rejected, because we want enable users to set page dates (those predefined). We'll however support attaching more dates to form-based pages that will allow them to sort and select based on that.
Piotr Gabryjeluk
visit my blog
Your comment makes no sense.
The wish is to "set page dates to past dates or future dates" and you say "it's rejected because we want [to] enable users to set page dates…"
Sorry, but your logic escapes me. Is the wish going to be implemented, yes or no? If no, why the heck not, after so many votes and discussion. And if yes, why mark it as rejected?
Portfolio
What's "page date" anyways.
Piotr Gabryjeluk
visit my blog
In my understanding: page dates are two dates:
We will still assure they are authentic and will NOT allow people to change them as they wish.
This is why this wish is rejected.
If you have another understanding of "page date" please create another — more explicit — wish.
Piotr Gabryjeluk
visit my blog
In that case, I would suggest that we want an attribute called %%published_at%% which is properly accessible to us via listpages etc. That is, an attribute that we can use to select and order pages by and which we can set a value for.
Sue
As described above, form data are proper properties, are accessible in ListPages and date fields will be usable for selecting and ordering. So we don't need any new hardcoded property of pages.
Piotr Gabryjeluk
visit my blog