SparklingSoftware / DokuWiki-Plugin-RevisionsDue

Displays a list of pages that should be revised
http://www.dokuwiki.org/plugin:revisionsdue
1 stars 3 forks source link

Plugin not working under working under Release 2012-10-13 "Adora Belle"? #2

Closed joemouth closed 11 years ago

joemouth commented 11 years ago

Hi, I installed your plugin Last updated on 2012-03-20 under DW Release 2012-10-13 "Adora Belle".

Unfortunately it seems not to be working: 1) Pages with <revision_frequency>123</revision_frequency> still displays the complete syntax.

2) Page with ~~REVISIONS:all~~ has a lot of warnings: 2.1) Warning: Invalid argument supplied for foreach() in /var/........wiki/lib/plugins/revisionsdue/syntax.php on line 220 2.2) The list of pages does not list the pages with <revision_frequency>

What can we do? Thanks!

chlw commented 11 years ago

Same issue here...

I already had some issues with the previous version of DokuWiki (don't remember which), but now it's definitely not working...

I get a list when having REVISIONS:all in the page systax, but all the pages that use the frequency-tag are not displayed in the resulting table (instead of being displayed).

Any help would be much appreciated.

Thanks

chlw

SparklingSoftware commented 11 years ago

Ok, no worries. I'll have a look shortly.

SparklingSoftware commented 11 years ago

Ok, I checked the use of the plugin and cannot find any issues with it. So perhaps its the user guide I need to update.

The idea is to specify the frequency of which pages have to be revised. So 365 means that someone has to check the page once a year. If someone updates that page half way through the year, the revision due date shifts accordingly.

What technically happens is that dokuwiki checks the last updated date of a page and if updated date + frequency is bigger than today, then the revision is due: LastUpdated + Frequency > Today. If not frequency is specified, it is allways added to the list, taking a worse case approach.

Have a look at: http://www.instantalm.org/doku.php?id=wiki:revisions

As you can see, the start page: http://www.instantalm.org/doku.php?id=start has a frequency of 365 and doesn't show up in the list. I've tested it, if i change it to -5 for instance, it does come up.

Please advise if things make more sense knowing this and whether or not you think there are indeed bugs that I haven't found, or that I perhaps need to update the documentation of the plugin?

Thanks!

chlw commented 11 years ago

Thanks for the clarification!

I didn't know about your concept, so describing that in the documentation would be of great help for the users. You are right, the plugin works exactly as describerd, once I knew it... :-)

May I make some remarks / questions about the concept?

In your concept, every page has to be revised every now and then. So you have therefore built in what you call a "worst case scenario" wiht every page coming up to the list with no revision date or no metadata-flag. This is a good idea when every page has to be revised.

I have a wiki, where only a few of the pages need to be revised on a regular basis. So I could put a metadata-flag on every page and set the frequency to say 500 years. That way, my pages that do not need to be revised would not show up. But this is not very handy and an easily forgotten. For my wiki, a better solution would be to either see on the list just the pages who need revision (the flagged ones; either all of them or just the ones overdue) or at least to exclude the worst case scenario (which I think results in the same output).

Do you have any hint what I must change in the code to accomplish this?

And another question: What is supposed to show up in the frequency column (see attached screenshot)? I guess the frequency in days? Does that only work with positive numbers (i have tried with -5 as you mentioned it above)? Pages with no metadata-flag do not have figures for obvious reasond, but the ons having a flag sould come up, don't they?

snap0013

Thanks again for any help, which is much appreciated, as all of your work is!

SparklingSoftware commented 11 years ago

Thanks for the suggestions. I'll update the doco as soon a I find an hour of spare time, which most likely be on the other side of new year.

I think you have a valid use case that the revision regime might not be applicable to all pages. Looking back at what I've implemented is that I've basically made revisions mandatory for all pages. So perhaps what I need to do is to implement a parameter like: "NO_REVISIONS" and "REVISIONS", in stead of the "ALL". The second is what you want, as that will only show the pages that have the revision xml in the page.

The other option is to implement a configuration switch, but that would apply across the entire wiki and the plugin already has the option to access parameters, so the solution above feel the most elegant.

What do you reckon?

Yeah... Those second and third column are pretty obvious Bugs... :-) :-) The third column should show the date it should have been revised at. That doesn't seem to work either...

Being the author It didn't bother me, but I can imagine it being pretty important info for non-authors and even more for non technical user.

When I'm implementing the above parameter, I'll also fix those. I had a brief look and it should work, so it's probably a typo/capital/missing $ sign somewhere. (I'm from a C# background, so php feels very "flexible" :-) to me).

Again, thanks for the suggestions and comments, getting actual user feedback is invaluable.

Feel free to fork the code and have a bash at implementing a solution. I'm not precious about my code. In fact I copied 90% of it from other plugins, so how can I :-)

One last question, are you German by any chance?

Cheers, Stephan

SparklingSoftware commented 11 years ago

I was foolish enough to "Just have a quick look" :-) Anyway, as you can see by the timestamps of the comments, it took me only an hour to fix the issues.

I had to update the regex to cater for negative numbers, which now works properly.

I also implemented the revisions parameter like this: REVISIONS:revisions to only show revisioned pages.

Nice... more doco.... just what I wanted... :-)

Can you check to see whether this also works on your wiki. Being a pro, I only tested it for like 10 min, so don't hesitate to contact me with issues. Although please create different issues in github if the issues are unrelated.

Cheers, Stephan

chlw commented 11 years ago

Dear Stephan

First of all: I am Swiss, therefore definitely of German mother tongue (as you might guessd from the screenshots)...

Second: Thanks for the quick reply and solution (don't you have family or friends to be with those Christmas days...? :-).

This is exactly what I needed. I copied your new syntax.php from the "code" register above and it seems to work pretty well. There is probably one more small bug in the code, as the pages with positive numbers (revision due in the future) now show up in the list, but the dates are wrong and the days don't show up (see screenshot; table and code from pages all in one picture). I'm positive that you can fix that easily in just minutes... :-)

snap0016

The new "REVISIONS:revision"-tag works great! And as you can see in the screenshot I use another plugin to comment out the frequency-xml (/.../), which also works great.

Im no coder / programmer at all, just a user. This makes it quite difficult (if not impossible) to make such more sophisticated changes to the code.

Again: thank you very much and have a good time!

Christoph (btw... ;-) aka chlw

PS: I keep the conversation here in english, so more people can profit from it.

chlw commented 11 years ago

Hi Stephan

I managed to find a solution for the problem mentioned above. I opened a "fork" and put the code in there (it's the first time I do, so I don't really know, whether this is ok like this).

Now everything seems to work fine.

I have attached a screenshot. I also have made a translation to Geman and included a table header (should I post the syntax.php file here? Or include that in the fork?).

I have seen that the table is sorted with a "uasort"-function, but I haven't managed to find out how that works so that I can get the table sorted ascending by the rightmost column. Any hints?

Thanks!

Cheers

Christoph

snap0019

SparklingSoftware commented 11 years ago

Hi Christoph,

Sorry for the late reply, Christmas and family got in the way! :) Didn’t you make a comment about that??? :)

I’m glad you’re not German btw, as I’m Dutch and we Dutchies don’t particularly like Germans :) :).

What you can do is push your changes to your fork on github (seems like you’ve done that for the syntax.php, I cannot see the new language file btw) and then click on the “Pull request” button.

Github then sends me a notification and the option to… (drum roll….) pull! This magic is not Git, but the Github website and works because you’ve created a Fork out of my repo.

FYI: A fork initially doesn’t contain any code, just links to the master repo files. Once you changes files, then the fork starts to contain code, but only the changes. Does that make sense? If not, forget what I said, it’s not important.

From the top of my head, The uasort takes two parameters. 1) the array to sort, 2) the function to determine the sorting order, in this case function date_compare.

Depending on the return value, the data is sorted differently. See http://php.net/manual/en/function.uasort.php

So to make the sorting work for a different column, I would probably implement a second sorting comparison function called due_date_compare and depending on a switch call either the current one or the new one. That solution doesn’t scale very well, but let’s cross that potential bridge when we get there.

I’ll try your changes probably this weekend. Further social commitments will get in the way of more fun. We’re only in The Netherlands for 5 weeks so everyone we ever knew is trying to get some attention from us :)

Cheers mate!

Stephan

From: chlw [mailto:notifications@github.com] Sent: Thursday, 27 December 2012 12:12 AM To: SparklingSoftware/DokuWiki-Plugin-RevisionsDue Cc: SparklingSoftware Subject: Re: [DokuWiki-Plugin-RevisionsDue] Plugin not working under working under Release 2012-10-13 "Adora Belle"? (#2)

Hi Stephan

I managed to find a solution for the problem mentioned above. I opened a "fork" and put the code in there (it's the first time I do, so I don't really know, whether this is ok like this).

Now everything seems to work fine.

I have attached a screenshot. I also have made a translation to Geman and included a table header (should I post the syntax.php file here? Or include that in the fork?).

I have seen that the table is sorted with a "uasort"-function, but I haven't managed to find out how that works so that I can get the table sorted ascending by the rightmost column. Any hints?

Thanks!

Cheers

Christoph

https://f.cloud.github.com/assets/1791707/31117/8e160c96-4f5d-11e2-8ad7-31ba675f47ac.gif

— Reply to this email directly or view it on GitHub https://github.com/SparklingSoftware/DokuWiki-Plugin-RevisionsDue/issues/2#issuecomment-11686168 .

https://github.com/notifications/beacon/uM_aGQZa3AxgnkFZKG8q2U-eu_weezA3ggYqDHGg_lNpLqwGxQ9EVo42g6Wv2cEO.gif

chlw commented 11 years ago

Hi Stephan

I put the file "syntax.php" with the German translation, my fix and the table with a header cell on "my fork". I hope I did that how it is intended...

For the sorting, I had a look into that before, but "oh my god!": this is definitely something for programmers (or at least I have to have a lot of spare time to find out how this would work).

I also have some days in the festive season, so no hurry!

Thanks for looking into it and have a good time!

Cheers

Christoph

PS: It seems you are living in Australia and returning to the Netherlands for holidays, right?

SparklingSoftware commented 11 years ago

Hi Christoph,

You had me on the wrong track with your translation! DokuWiki has the build in localization capability where plugins can read text from language files and I though you had implemented that. I was scratching my head for a couple of seconds, thinking you might have forgotten to push it into your GIT repo.

Anyway, I'll implement it properly so you get your German headers :-) I'll let you know when I've pushed up those changes, if you can write the German translation, that would be great!

(And I know a bit of German, so I know when you are mocking with me! ((Including "Immer Gerade Aus" which we use for German tourists who are asking for directions when invading our beaching every summer :-) :-))

Yes, we are in The Netherlands for some nice cold weather again, which we certainly managed....

I'll also create an option to specify the column to sort.

Cheers, Stephan

chlw commented 11 years ago

Dear Stephan

No problem, just let me know, when you have that. German translation ist no big deal, I can do that.

I know that reading from localization files is possible, but doing that is also far too complicated for me as I don't understand the underlying concepts. And digging into that is an impossible thing (definitely no time...), at least at the moment.

I usually do all my programming work by trying... :-(

But again: thanks a lot for your excellent work with all that! If I can help, just let me know

Cheers

Christoph