I'd like to see parameters in ListPages to select pages based on when they were edited. (Maybe there's a work around, but I noodled this around for a while and can't seem to come up with anything not involving copious amounts of JavaScript.) My thought is to have an last_edit_before, revised_before, last_edit_after, and revised_after parameters. revised_before and revised_after would check for any revision before/after/between the given dates. last_edit fields would check only the most recent revision. _before and _after fields would be additive, allowing selection of pages edited in a range of dates, say, in a given day or week.
In a site with over 1,000 pages and 2.5 years of development, and authors who may edit several dozen pages a day during production mode, it would be nice to be able to search by edits to be able to track the progress actually being made on given days, weeks, and months.
It is already possible to do this with the creation date, so this would be nice parallel functionality.
You could do this with the API, read documentation http://www.wikidot.com/doc:api-methods#toc6
there is a method get_meta that allows you to select pages by revision, update and creation..
So IMHO I think it is already possible to things like this.
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
*Sigh*
You know, the more and more I use Wikidot, the more I come to the conclusion that Wikidot sells itself with an image of simplicity and easy usage, but the truth is if one really wants to use the full capabilities of this site, then one often must research rather convoluted hacks (like default parameters for includes or nested ListPages), or else one must know 1+ programming languages (like this, or sortable tables).
We chose wikidot because of the simplicity and the free cost. The amount of time I've invested on the technical side of solutions suggests it has not been simple. Every time I have to use a solution like those means another section of the project becomes my sole responsibility, for my fellow authors are not programmers.
I'm already the primary author and editor along with co-designer for all our creative content. This project was never supposed to need a programmer in the first place. Sadly this has led to some serious talks about leaving the wikidot platform. I've reached the point where the bizarre limitations/functionality ("advanced" tables not having any way to make a TH, no nesting listpages, the 'interesting' result of including a page from a category with a form, etc.), site unreliability and the need to learn rather involved techniques to do things I could do so easily with PHP + SQL (like this), makes yearn a host with Apache, PHP and an SQL db.
If I had a couple fellow programmers to share some of the technical load, this would be no big deal.
*Ok, end rant.*
Guess it's time to start using the API.
I know what you mean. It seems that often when we make a wish for an added feature, one of our young, brilliant gurus is able to figure out some kind of workaround that may or may not be exactly what we want, but might work as a short-term fix. My head still spins when I try to decipher some of the advanced coding techniques that are used to hack the output of ListPages or a data form template or clever includes that go a couple of levels deep.
When I try to help others do something that can't be done easily, I find myself spending most of my time trying to come up with some kind of workaround. The only partial workaround that comes to mind for this issue is to order your pages by updated_at desc to at least get the most recently edited pages at the top of the list.
It would be so refreshing if we heard something from the development team like: "Yes, we think this is a great idea too! We should be able to implement it for you within a couple of weeks."
Bootstrap Playground - Wikidot Meets Twitter Bootstrap!
Wikidot API - PHP · A PHP client and code samples for the Wikidot API
I can assure you that moving to a different platform will give you the same issues, or probably worse as Wikidot has more functionality than most of its competitors. I use the Confluence Enterprise Wiki on a daily basis and I tear my hair out trying to do things that are very easy on Wikidot or where at least there is a workaround on Wikidot. Workarounds on Confluence are all but impossible. I occasionally have to use the Sharepoint wiki and it's a disaster. I doubt that any of the other popular (and free) wikis come close to things like ListPages or Dataforms or other advanced functionality that we have here.
Yes we have our frustrations here at Wikidot in terms of delivery of new features and the many things that we would like to see implemented, but I do not know of another wiki platform that is as flexible or powerful as Wikidot. Once you move away from the basics it can be a challenge and requires an interest in coding or CSS or whatever. But another platform would be the same, and in the case of Confluence any extra functionality usually costs hundreds of dollars.
Eh? yes there is, Why do you think this is not possible? Use CSS either in your main CSS page for site-wide or in a CSS module for a single page:
For example if you use a CSS module it would look like this::
Then reference it in the table:
That's a very simple example and you can make the table and the header row look a lot better.
Don't forget to ask questions like this on the community forum.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
I agree completely. I pull my hair out almost on a daily basis trying to re-organise our corporate Confluence wiki. If Wikidot Open-Source could be installed locally (or at least some form of Wikidot), I'd highly recommend that instead for sure.
Shane Smith
Web Developer and Wikidot Community Administrator
Links: Blog, Wikimated, Editor (STE), Documentation
Ed, the updated_at ordering is what we've been doing, but, when there's dozens of edits a day and I want to say, look through the summer of '09 and see what we were developing then… doesn't help that
Rob Elliot, I know how to do the workaround on tables. (It gets harder as a header row in a prepend line on a ListPages module call where you can't assign a class or a style. In that situation I put the the module call in a div with an ID or class, then use css to address the table inside the div and set the default style, which the top row gets. Then I'd format the rows/cells that are the body of the listpages output by assigning them classes and override the default formatting which the top row got.) Again, a convoluted work-around, this time to set a style and/or id in the prepend line of ListPages, because apparently nobody thought it would be a good idea to handle basic escaping of text for those parameters.
How could one make ListPages and NOT think that people would want to use it to put data in tables and want to format those tables? I mean, seriously, making tables is like day one at ListPages academy. And tables, rows, and cells are made to take id and class parameters which are enclosed in quotes. It's like wikidot is incompatible with itself. And isn't it pretty darned common to have tables that have header rows? I didn't ask that as a question in the community forum because it isn't a question, it is a complaint.
But, RobElliot, your solution does not produce a TH, it formats a TD differently. TH is still part of HTML standard, right?
Let me be clear, I do like wikidot in general. I appreciate the service as a complete package, but there are aspects that disappoint me.
Here's where my problem with the th/td thing is, and where my frustration lies with many aspects of wikidot… I've programmed a fair bit. Some of the things that frustrate me here, my university professors never would have let slide.
For example, the amount of work to program "advanced" tables capable of producing both the TH and TD is so minimal that there's almost no reason to not implement it. It's adding some data to a list of parser tokens, and there's already an analog in the way that the parser handles simple tables and DOES produce THs. (While that would partially clean up the above mess with listpages and tables with header rows, it still doesn't remove my complaint about not being able to escape text in prependline and appendline.)
Another example. The output when you include a file from a category that uses forms - a list of keys and values - is nearly useless. Either eliminate the functionality or make the output useful. I can make these nice pages in a category with a form and a template, but the only way to include an entire page elsewhere is through a workaround using listpages, a unique page tag, and moving the template's contents into a file which both _template can include and I can use with listpages elsewhere. This type of fractured functionality where the same task has to be done in completely different ways is counter-intuitive and complex. Doesn't it seem strange that to include a single page as it appears on its own sometimes you use listpages, but sometimes you use include?
"Simplicity favors regularity." — a phrase any programmer worth his or her salt should know. When I see things like those examples, it just makes me scratch my head and think, …
The functionality I suggest in my original post is to try and make things simpler and more uniform. Why should an api call be necessary for this selecting a file by revision date(s)? That is the opposite of simplicity and makes it essentially impossible for non-programmers to use.
And if you think I'm overplaying the simple thing, look at the front page of wikidot.com, and look at how many of their testimonial quotes mention how simple and fast it is…
Even though you have guru status we can't always remember who knows how to do what so sometimes the answers might seem a little simplistic.
You method of dealing with tables seems particularly complex. I'd be interested to see an example to see if we can't help to make your life a little simpler.
You mentioned all the comments about simplicity on the Wikidot main site. As far as I can tell it is a minority of users who delve into the intricacies of ListPages, Dataforms etc etc. Most users are not programmers like yourself or have any knowledge of css. Whilst I desperately wish Wikidot would do more development tailored to advanced users, I suspect its core base is always likely to be people who never stray from the basic syntax, simple tables, default ListPage functionalty and so on. It excels at providing a quick and easy platform for those users.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
It's far from a wordaround less method — but you can always include inside prependLine and appendLine:
ListPages:
inc:table-header:
Kenneth Tsang (@jxeeno)
It does provide just that. But those same users, if something isn't part of the basic functionality of the site (e.g. an argument for a module, compared to using the API), then those less tech-savy users will never even have the option to use it.
Every solution that requires the API (or similar advanced tech knowledge) is one that non-programmers cannot use. This site is like the home computer, meant for usage by the general population. While I love changing the keyboard layout to Dvorak, I don't do it to the home computer because then the users won't be able to use it. Like the Dvorak keyboard layout, requiring usage of the API syntax (or other complex work arounds) just shuts out the general user.
While the basic user is not likely to stray from the simplest syntax, it is nice to have the tools accessible for them so they at least have the ability. And the more user friendly the tools are (and documentation), the more likely they are to be used when needed.
I am not sure, but I think …
(partially) solved with http://feedback.wikidot.com/wish:956 Add updated_at selector to ListPages module
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?