HI there,
We are having trouble with the cvs, some of dfwikiteam developers seem to have been removed from de sourceforge acl and this kind of things...
So I've posted the last version of wiki in the dfwiki home so you guys can test if works fine with UTF. so far I have'nt test it but Berna says it works..
Regards
Ludo
http://appserv.lsi.upc.es/palangana/moodle/course/view.php?id=15
Hi
I installed dfwiki on Moodle 1.6 Beta 2 (2006040500) Win2k Xampp.
1. Can't save any content. After editing when I click Save button I get "No content" message
2. Only dfwiki editor usable. Drop down list contains HTMLeditor, but editor never changes
3. No lang file in included in zip file. I use lang file from previous release.
No errors in apache error.log.
Teemu
I installed dfwiki on Moodle 1.6 Beta 2 (2006040500) Win2k Xampp.
1. Can't save any content. After editing when I click Save button I get "No content" message
2. Only dfwiki editor usable. Drop down list contains HTMLeditor, but editor never changes
3. No lang file in included in zip file. I use lang file from previous release.
No errors in apache error.log.
Teemu
Thanks Martin,
althougth there are lots of interested I'm almost not receiving feedback on the new wiki, and every day are comming suggestions and requests for dfwiki. I think that we'll get enougth feedback if we squeeeze it in the next beta
: I'll have the developers ready and steady for the bug fixing feast (that rigth now we are loosing
).
How do you see it?
Ludo
althougth there are lots of interested I'm almost not receiving feedback on the new wiki, and every day are comming suggestions and requests for dfwiki. I think that we'll get enougth feedback if we squeeeze it in the next beta
: I'll have the developers ready and steady for the bug fixing feast (that rigth now we are loosing).How do you see it?
Ludo
Hi!
IMHO dfwiki is NOT ready for inclusion into main cvs, because there are still following problems:
IMHO dfwiki is NOT ready for inclusion into main cvs, because there are still following problems:
- reliance on register globals, old xxx_variable() functions - all of them must be properly converted to new xxx_param() functions
- incorrect use of xxx_param() functions - please do read the function definitions and comments; please make sure that all dfwiki developers understand these two functions
- remove those global variables - use function parameters instead; this is IMO priority #1
- use p() and s() functions in forms
- fix XHTML compliance
- please use only English in comments/code - do you want me to comment my code in Czech too?
I've posted this elsewhere but since it isn't really clear where your developers are monitoring, I add it here just to make sure it isn't overlooked:
username is used to identify the user in the database instead of userid. This is also displayed to students and teachers instead of user's fullname. This is a serious bug because it poses a security risk to students by revealing their userid to all, and it is also a serious issue because anyone can change their username at any time, unlike userid. This problem exists in both Dfwiki and the new wiki.
username is used to identify the user in the database instead of userid. This is also displayed to students and teachers instead of user's fullname. This is a serious bug because it poses a security risk to students by revealing their userid to all, and it is also a serious issue because anyone can change their username at any time, unlike userid. This problem exists in both Dfwiki and the new wiki.
Petr ,
I've cheched and I believe you have looked into dfwiki, not in wiki module. Cause most of things you list are fixed.
But
- the use of globals HAS to be removed. I agree completelly, sorry I don't read all the code. But IMO it can wait. I prefer to focuss on getting a stable wiki and then start tunning the code. It will take some time and we can do it gradually in the future.
So Martin, Can it wait?
Ludo
I've cheched and I believe you have looked into dfwiki, not in wiki module. Cause most of things you list are fixed.
But
- the use of globals HAS to be removed. I agree completelly, sorry I don't read all the code. But IMO it can wait. I prefer to focuss on getting a stable wiki and then start tunning the code. It will take some time and we can do it gradually in the future.
So Martin, Can it wait?
Ludo
Hi Ludo,
I have looked many places trying to find current code - I believe I found it. The only correct place for it is contrib cvs, I can not help you if it is elsewhere. Please remove any obsoleted versions from there too. Please let me know when you clean up the contrib.
I guess there are several security related problems in dfwiki, I would like to help but I am not going spend my free time on code that is full of global variables, sorry.
Coding style is very important, because others can find/fix problems much more easily.
skodak
I have looked many places trying to find current code - I believe I found it. The only correct place for it is contrib cvs, I can not help you if it is elsewhere. Please remove any obsoleted versions from there too. Please let me know when you clean up the contrib.
I guess there are several security related problems in dfwiki, I would like to help but I am not going spend my free time on code that is full of global variables, sorry.
Coding style is very important, because others can find/fix problems much more easily.
skodak
Hi Petr,
you're absolutelly rigth about codig style. DFwiki was boun out of a student's degree project that grew grew and grew... Now is becomming mature and there is on developer focussed only in bug fixing and code tunning, rigth now I'm more concerned on stability. But we are on it.
Thank you
Ludo
ps. we had some trouble with last sourceforge cvs "cuac", I'll infomr when I'm sure last versions are on the cvs. By the way the new module is on contrib/dfwiki/mod/wiki
you're absolutelly rigth about codig style. DFwiki was boun out of a student's degree project that grew grew and grew... Now is becomming mature and there is on developer focussed only in bug fixing and code tunning, rigth now I'm more concerned on stability. But we are on it.
Thank you
Ludo
ps. we had some trouble with last sourceforge cvs "cuac", I'll infomr when I'm sure last versions are on the cvs. By the way the new module is on contrib/dfwiki/mod/wiki
!
I have just installed wiki vers. 2006041201,
downloaded from the dfWiki site
http://appserv.lsi.upc.es/palangana/moodle/course/view.php?id=15
the language files included in the package do not appear to be the correct files; most of the required strings are missing from these.
Do you have the proper language files? (I'm needing English only for my installation)
thanks,
will
downloaded from the dfWiki site
http://appserv.lsi.upc.es/palangana/moodle/course/view.php?id=15
the language files included in the package do not appear to be the correct files; most of the required strings are missing from these.
Do you have the proper language files? (I'm needing English only for my installation)
thanks,
will
We developed the first dfwiki when moodle 1.5 was still beta and we found no standard way to put blocs into the activity... so we hacked our way out. I'll tell one developer to port our blocks to moodle standard blocs. This is more or less prioritary than global variables ?? Just to schedule.
About the CVS ok.. we are merging in the main directories... there was tree functionalities developed by new students ( discussion, voter for pages, and improved diff features that we needed to merge... so this file version will be considered as #1... from now on we'll allways work on main cvs... but all these files are related to dfwiki not to wiki.
Regards
Ludo
About the CVS ok.. we are merging in the main directories... there was tree functionalities developed by new students ( discussion, voter for pages, and improved diff features that we needed to merge... so this file version will be considered as #1... from now on we'll allways work on main cvs... but all these files are related to dfwiki not to wiki.
Regards
Ludo
Hi there,
Im pasting here a list of issues in wich we have been working these days... The basic list comes from a large document Eloi provided us and we kept from there.
Ludo
ps. bernardino todoli is makin a hell of a job
- In the upgrade from wiki to dfwiki, as there aren't userids, my wiki-pages were assigned to "guest".
- SOLVED: Exactly the same error is showed with any of the 3 tabs (view, edit, history)
- Some help files are mising (contributions...)
Im pasting here a list of issues in wich we have been working these days... The basic list comes from a large document Eloi provided us and we kept from there.
Ludo
ps. bernardino todoli is makin a hell of a job
- SOLVED: There is a bug in the versions, so the upgrade from old wiki to new never happens.
- There are a lot of tabs here and there. They must be changed to 4 whitespaces each.
Where?
- There is no userid column in the wiki_pages table (author char-string instead).
Thats like in the original wiki
- The blocks structure isn't build over core blocks tables but over its own. Some records are harcoded in the blocks tables instead of allowing standard block installation/upgrade. I would create a bunch of wiki_xxxx standard blocks instead, only usable under the wiki pages, of course. Also, their strings should be present in the propper files and some other details to become standard blocks.
- wiki_synonymous table name is correct? (although it's possible that migation become painful, so we can change it in the future...).
Yes, its correct
- wiki_synonymous table hasn't pageid, is it needed? How does it work? Just by pagename?
Yes, with only the original entry (pagename) works fine
- Are pagenames sticky? Cannot they be renamed (moved in mediawiki language)?
Yes, they can be renamed. Thats at Administration Tools block in the update page xxx utility
- The Wiki icon. I cannot see anything meaningful
there! (personal opinion, of course)
It seems to become corrupt either after the migration process or CVS problem with images
- In the upgrade from wiki to dfwiki, as there aren't userids, my wiki-pages were assigned to "guest".
- SOLVED: When one page with more than 1 version is retrived from DB, I get:
Error: Turn off debugging to hide this error.
SELECT * FROM mdl_wiki_pages WHERE pagename = 'One utf-8 page' AND dfwiki = '1' AND groupid = '0' LIMIT 100
Found more than one record in get_record_sql !
It seems to be related with the anonymous block executing one wrong get_record() call!
- SOLVED: Exactly the same error is showed with any of the 3 tabs (view, edit, history)
- Some help files are mising (contributions...)
Done. CVS updated
- Some strings are mising (resultincontent...)
Done. CVS updated
- Search doesn't work for diacritics. And/or match is performed with case matching (I think).
- Search seems to work against titles and contents always (no matter the checkbox was selected or no). Perhaps it's due to that usage of globals?
Ah! After a second try I saw that such checkbox is to decide to show the details of the search in the body of the page. Perhaps the title should be changed to be a bit more clear? Something like "show results page" and some sort of nice help...
Ok
- The text in some blocks (search, index from current... doesn't wraps, so blocks get wider and wider).
Done. A trim function is implemented already.
- The useful "who links here" block isn't available.
- Adding a block always jump to module main page. It should be retained.
fixed
- The wiki title in the breadcrumb should be linked to the main page to be able to go there quickly.
Done
- Wiki backup and restore don't suppor individual activities!
- Wikies aren't included in the backup/restore at all!
- PostgreSQL upgrade script isn't available!
- UTF-8 migration always get user_main_language() and it should get page author language!
Its done the same way as in the Forum migration
- There is one bar with one big "dfwiki" inside at the begining og each block. If it hasn't any use, it should go away.
Fixed
- In the wiki_pages table there is one "dfwiki" field. Should be "wikiid". Such name doesn't sound ok. (although it's possible that migation become painful, so we can change it in the future...).
- If the name of the page contains ' or " or \ it gets slashes when previewing. Also, < and > seem to be stripped and links are broken (because of quotes?).
It works fine in my local version. More details are needed to fix the problem.
- Page names containing ' produce this SQL errors because of un-slashed:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's page' AND dfwiki = '1' LIMIT 100' at line 1
SELECT * FROM mdl_wiki_synonymous WHERE syn = 'Helen's page' AND dfwiki = '1' LIMIT 100
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's page' AND dfwiki=1 AND groupid=0 LIMIT 100' at line 3
SELECT MAX(version) AS maxim FROM mdl_wiki_pages WHERE pagename='Helen's page' AND dfwiki=1 AND groupid=0 LIMIT 100
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's page' AND dfwiki = '1' AND groupid = '0' LIMIT 1' at line 1
SELECT * FROM mdl_wiki_pages WHERE pagename = 'Helen's page' AND dfwiki = '1' AND groupid = '0' LIMIT 1
It works fine in my local version. More details are needed to fix the problem.
- dfwiki is inside a lot of places in code. It should go out (although it's possible that migation become painful, so we can change it in the future...).
Ok
- globals, globals, globals usage should be out. Just request parameters filtered with xxxx_param() functions.
Work in progress
- Uses ob mb_xxxxx() functions. Fatal error: Call to undefined function mb_internal_encoding() in C:\cvs_moodle\moodle_head\mod\wiki\blocks\list_pages\block_list_pages.php on line 145.
Fixed. Text class used instead.
- Uses of htmlentities() should use s() and or p() instead. It isn't utf-8 safe! Only for display text!
Done
- Analyse uses of htmlspecialchars(). If they are used to display text, consider swithing to s() and p() too.
Done
Ludo,
I installed the latest version of the new wiki and am having this problem with the html-editor; see appended image, the editing area is not there! I don't know if this has something to do with wiki or moodle in general but I never experienced this problem before.
It seems as if the problem only occurs in IE6 (which I have to use most of the time). In Firefox the problem did not occur (until now).
Hope you can help me! Jos
Hi Ludo,
I've been working a bit this weekend against your wiki code (helping where I've been able to patch without adding risks) and here it's the list again, updated and with some of the points in the previous one deleted (although not fully tested).
Perhaps we could maintain the numbering for further reference (or send this to MoodleDocs too):
Under my perspective, the lack of userid is really a big problem, because it's basic for all the system to have such info coded (migration, backup, utf-8, other functionalities...).
Also related it's the lack of support for student-based wikis (I assume that you support course (or common) and group based wikis without problems, although I haven't tested it). The big conceptual difference between the old wiki and your great wiki is that the old one supported different lines of versioning (for each group or for each student we have versions 1,2,3...) while your alternative seems to lack this.
Hope this helps, ciao
P.D.: At home I've some changes pending to be sent, affecting point (2) above and adding some changes to the migration script (without changing anything but the style of database calls and support for (2) ). Obviously the problems related above about the old-new migration will remain until we have userid and student-based wikis in your module
P.D.: Another thing that is lately rounding over my head is HOW all these changes over your wiki module will affect your dfwiki module. Does dfwiki module continue its own development? Is there only one module?
I've been working a bit this weekend against your wiki code (helping where I've been able to patch without adding risks) and here it's the list again, updated and with some of the points in the previous one deleted (although not fully tested).
Perhaps we could maintain the numbering for further reference (or send this to MoodleDocs too):
- There is no userid column in the wiki_pages table (author char-string instead). Must be supported in migration too.
- There is no intro and introformat in the wiki table.
- In the upgrade from wiki to dfwiki, as there aren't userids, my wiki-pages were assigned to "guest". Once more, userid seems to be critical.
- Wikis having different wiki_entries (group or user ones) have no support in new wiki (only one simultaneous line of versions is available?) so we get a lot of duplicate version errors with data-lost of such pedagogical feature! Or am I losing anything? With only groupid and version in the UK of the table, old student wikis can fit in the new one. Once more, userid!
- Search doesn't work for diacritics. And/or match is performed with case matching (I think).
- Search seems to work against titles and contents always (no matter the checkbox was selected or no). Perhaps it's due to that usage of globals?
Ah! After a second try I saw that such checkbox is to decide to show the details of the search in the body of the page. Perhaps the title should be changed to be a bit more clear? Something like "show results page" and some sort of nice help...
- The useful "who links here" block isn't available.
- Wiki backup and restore don't suppor individual activities!
- Wikies aren't included in the backup/restore at all!
- Blocks system. Would be difficult to migrate to core block system?
- UTF-8 migration always get teacher_main_language() and it should get page author language! If we know the author responsible of the version, we must look for his original encoding instead of using the teacher one! Similar to forum_posts (if I'm nor wrong). And we should know the user: userid again!
- In the wiki_pages table there is one "dfwiki" field. Should be "wikiid". Such name doesn't sound ok. (although it's possible that migation become painful, so we can change it in the future...).
- dfwiki is inside a lot of places in code. It should go out (although it's possible that migation become painful, so we can change it in the future...).
- globals, globals, globals usage should be out. Just request parameters filtered with xxxx_param() functions.
- Attachment storage (as I've seen in the old-new migration script) seems to be a bit special with a lot of "dfwikiXXXX" dirs generated.
- The old-new migration script seems to be twice, once under the wikimigrate dir (the used one) and under the mod directory (unused?).
Under my perspective, the lack of userid is really a big problem, because it's basic for all the system to have such info coded (migration, backup, utf-8, other functionalities...).
Also related it's the lack of support for student-based wikis (I assume that you support course (or common) and group based wikis without problems, although I haven't tested it). The big conceptual difference between the old wiki and your great wiki is that the old one supported different lines of versioning (for each group or for each student we have versions 1,2,3...) while your alternative seems to lack this.
Hope this helps, ciao
P.D.: At home I've some changes pending to be sent, affecting point (2) above and adding some changes to the migration script (without changing anything but the style of database calls and support for (2) ). Obviously the problems related above about the old-new migration will remain until we have userid and student-based wikis in your module
P.D.: Another thing that is lately rounding over my head is HOW all these changes over your wiki module will affect your dfwiki module. Does dfwiki module continue its own development? Is there only one module?
Hi Eloy,
thanks for your help!
I'm moving the list rigth now to docs.moodle.org ( I'm posting the link in further message).
We are working on the userid feature...
We have developed the student wiki fetaure but under dfwiki ( not yet released ), now that the studed who madei it knows his way arround he'll apply it over the new wiki.
Rigth now we are using the dfwiki as a testground for new functionalities. I know we'll have to deal with a precess of merging, but I prefer to use dfwiki as a test ground so the features can be tested safely by everyone. So the new wiki and dfwiki can coexist. The idea is -> new wiki stable stuff, dfwiki -> mad ideas for daredevils. You know I have lots of mad ideas
Thanks again, ciao
Ludo
ps. If you come to barcelona this friday, you'll be able to see some members of dfwiki team featuring hard rock songs live http://appserv.lsi.upc.es/palangana/moodle/course/view.php?id=12&edit=off
thanks for your help!
I'm moving the list rigth now to docs.moodle.org ( I'm posting the link in further message).
We are working on the userid feature...
We have developed the student wiki fetaure but under dfwiki ( not yet released ), now that the studed who madei it knows his way arround he'll apply it over the new wiki.
Rigth now we are using the dfwiki as a testground for new functionalities. I know we'll have to deal with a precess of merging, but I prefer to use dfwiki as a test ground so the features can be tested safely by everyone. So the new wiki and dfwiki can coexist. The idea is -> new wiki stable stuff, dfwiki -> mad ideas for daredevils. You know I have lots of mad ideas
Thanks again, ciao
Ludo
ps. If you come to barcelona this friday, you'll be able to see some members of dfwiki team featuring hard rock songs live http://appserv.lsi.upc.es/palangana/moodle/course/view.php?id=12&edit=off
HI Eloy,
the issue list is placed here
http://docs.moodle.org/en/Wiki_requirements#New_Wiki_issue_list
Ciao
Ludo
the issue list is placed here
http://docs.moodle.org/en/Wiki_requirements#New_Wiki_issue_list
Ciao
Ludo
It seems that there is a fair bit of work to go. I just want you to know that I am still hoping and praying to see dfwiki in production.
My naive and uniformed impression is that there needs to be a little more emphasis on stage 6 of the Ludo methodology for managing moodle projects.
In any event I remain in hope, with bated breathe and gratitude for all the work so far
Tim
My naive and uniformed impression is that there needs to be a little more emphasis on stage 6 of the Ludo methodology for managing moodle projects.
In any event I remain in hope, with bated breathe and gratitude for all the work so far
Tim
Oh yes Timothy!!
You're rigth... after the first internalmail we readlized that we had to focuss on moodle-ing our desing, then we realised that codig style was also important (students are the ones who write the code, and they tend to be creative )... then came the security issues (security and wiki are alien concepts )... and then came eloy with looong lists of issues ... :-S
By the way, have you tested the discussions in latest dfwiki ? I think you'll like it.
Regards
Ludo
ps. Berna sends greetings
You're rigth... after the first internalmail we readlized that we had to focuss on moodle-ing our desing, then we realised that codig style was also important (students are the ones who write the code, and they tend to be creative )... then came the security issues (security and wiki are alien concepts )... and then came eloy with looong lists of issues ... :-S
By the way, have you tested the discussions in latest dfwiki ? I think you'll like it.
Regards
Ludo
ps. Berna sends greetings
I have downloaded today's version of dfwiki and will give it a try.
But until it is production safe-ish, my trials will be only me and very minimal alas.
By the way (thanks to Gustav, Eloy and Howard especially) I am using moodle 1.6 beta 4 in production. I am not a beta coward! Or rather, Moodle betas *work*.
Completely off topic, one of my seminar students says that the aikido club here at Yamaguchi university has only 10 first year, 2 second year and 4 third year students involved. Hence Yamaguchi is not the place for an Aikido officianando like Berna. Hi Berna.
Tim's right. Many students when they reach the real world will be hired to work on already existing pieces of software, not necessarily create new works. They will first need to get up to speed on what has already been done and the standards that exist for that software, and then put their creative skills to work within those parameters.
To be fair, I wouldn't say it is a problem only with DFWiki. I find a lot of non-standard modules in Moodle lack conformity with standard ones from the outset and lack the basics of a proper module. Things like an option to hide the module from the beginning for example or add its use to the logs, are lacking in a lot of contributed modules. A lot of people focus on what new things they can create without first building the foundation that will make their module work like a standard Moodle module. It might be worthwhile to put together a list and even code for must-have features in every module.
In fact, that might be a worthwhile assignment for some students itself. Have them study the existing standard Moodle code to identify the commonalities between all modules and extract the relevant code to create a module template.
To be fair, I wouldn't say it is a problem only with DFWiki. I find a lot of non-standard modules in Moodle lack conformity with standard ones from the outset and lack the basics of a proper module. Things like an option to hide the module from the beginning for example or add its use to the logs, are lacking in a lot of contributed modules. A lot of people focus on what new things they can create without first building the foundation that will make their module work like a standard Moodle module. It might be worthwhile to put together a list and even code for must-have features in every module.
In fact, that might be a worthwhile assignment for some students itself. Have them study the existing standard Moodle code to identify the commonalities between all modules and extract the relevant code to create a module template.
Everything that is comes out of its history...
And the very first lines of dfwiki came along while I was also learning to moodle. I completelly do agree with you Nicole, but we carry the weigth of our deeds and now we pay for our mistakes, so the team is learning the lesson the hard way. I don't consider it negative cause I cherrish each oportunity to learn a lesson...
Regards
Ludo
And the very first lines of dfwiki came along while I was also learning to moodle. I completelly do agree with you Nicole, but we carry the weigth of our deeds and now we pay for our mistakes, so the team is learning the lesson the hard way. I don't consider it negative cause I cherrish each oportunity to learn a lesson...
Regards
Ludo
Ludo-Please let us know when the userid issue is fixed. Because as far as I am concerned, this module is completely useless until that is fixed. As Eloy said, it is so critically important that all the new functionalities your team is focusing on are pointless until the wiki simply does the basic things any module should do properly. I'm ready and willing to put this to the test on a production site and give you feedback, but only if you fix this important problem first.
Hi Nicole (rigth?),
we are working on the userid issue this very week, I hope this will be fixed by let's say thursday.
As already explained to Martin once or twice, my team is mainly populated by students at their degree project. When they are new to the team they have to develop a new functionality, and stay away from the main version of the module... When they start to master moodle programming and dfwiki I allo them to lay their hands on sensible stuff as new wiki. All the new functionalities I present in todays release of dfwiki (not new wiki) have been developed by new students... the "expert" ones are working on fixing all the stuff.
I can't have 8 people working on the same task.
I thank you in advice for your offer.
Ludo
ps. do you happen to know the good JosepM Fontana, I readed that you where arroun bardelona lately? Let's have beer or cofee if you come back!
we are working on the userid issue this very week, I hope this will be fixed by let's say thursday.
As already explained to Martin once or twice, my team is mainly populated by students at their degree project. When they are new to the team they have to develop a new functionality, and stay away from the main version of the module... When they start to master moodle programming and dfwiki I allo them to lay their hands on sensible stuff as new wiki. All the new functionalities I present in todays release of dfwiki (not new wiki) have been developed by new students... the "expert" ones are working on fixing all the stuff.
I can't have 8 people working on the same task.
I thank you in advice for your offer.
Ludo
ps. do you happen to know the good JosepM Fontana, I readed that you where arroun bardelona lately? Let's have beer or cofee if you come back!
Ludo, you wrote
- Uses ob mb_xxxxx() functions. Fatal error: Call to undefined function mb_internal_encoding() in C:\cvs_moodle\moodle_head\mod\wiki\blocks\list_pages\block_list_pages.php on line 145.
Fixed. Text class used instead.
---------------------------------------------------------------------------
But to my experience this isn't fixed in the newest "wiki_2006042001.zip" (the wiki-version of dfwiki).
Can I in general be sure that all improvements of dfwiki are also being done in the wiki-version?
Another question: For layout purposes of the sideblocks I am editing tree.css. Is this the way it has to be done in future or is this just a temporary solution?
Thanks, Jos