Category: 2.x

Already possible:
http://profiles.tikiwiki.org/time_sheet

But it would be nicer to have a click on start, click on end to count time for you.

Something integrated to track time spent on ((doc:tasks))

Will be useful for ((project Management))


http://timeclock.sourceforge.net/
http://sourceforge.net/projects/phptimetracker/



Coordination happening at ((Federated Timesheets))

Tring to create a structure results in the error:
An error occured in a database query!

Context:
File tiki-admin_structures.php
Url tiki-admin_structures.php
Query:
insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`) values(?,?,?,?)
Values:
0 0
1 2
2 Test Structure
3 1
Message:
Field 'structure_id' doesn't have a default value
Built query was probably:
insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`) values('0','2','Test Structure','1')

If the process is repeated the error thrown is different: 1 page not added (Exists)

Found with clean installs of 2.0RC4 on Windows Server 2003 x32 and also server 2008 x64. PHP 5.2.6 (x32); MySQL 5.0.51b (x32 and x64); Apache 2.2.9 (x32)

the structure will not be sorted correctly in a wiki page while it is sorted as it should be in the structure

i tried to change the pos row in the database directly, but that doesn't helped

after expecting the db for these items i think i might know where the problem is - it is sorted by the page_ref_id instead of pos field

example (where pos is the position in database and the should be sort order) :

|| Page Name | pos | page_ref_id | pos in wikipage
Concept | 1 | 49 | 2
Exhibition | 2 | 75 | 4
Facilities | 3 | 24 | 1
Portal | 4 | 89 | 6
Handbook | 5 | 68 | 4
Resources | 6 | 55 | 3 ||

as you can see it is sorted after the page_Ref_id instead of pos in a wikipage

edit: on the other hand in another tiki there is no such problem as described above

Documentation of Tiki (doc.tw.o) needs some help, as well as any other tiki site aiming to produce structured documentatation to be exported as "printer-ready" (.pdf, .odt, ...)

!!- (1). Original idea, as posted in devel list (but improved, and made it easier, below, in (2) )
I include here a copy of the [http://sourceforge.net/mailarchive/forum.php?thread_name=467565F1.9080905%40ub.edu&forum_name=tikiwiki-devel|original post at tiki-devel list]:

{QUOTE()}
[Tikiwiki-devel] New documentation file: Tiki198alpha.pdf
From: Xavier de Pedro Puente <xavier.depedro@ub...> - 2007-06-17 16:44

(...)

There are some issues that, it solved from coders, they would make
easier to produce next documents like the pdf ones:

(1) Page Title is not automatically shown on wiki pages on the server,
and thus, manual header1 was added everywhere (Almost). But when
printing to html, page title is duplicated. => if Show Page Title option
is disabled under "Admin > Wiki", Page title should not be added
automatically at print-to-html time.

(2) to produce the same structure (same level structure of headings) as
in table of contents http://doc.tikiwiki.org/Documentation , some hack
(optional) would be very welcome so that heading 1 in doc.tw.o pages is
not printed as heading 1 in through the multiprint, but as header 2, at
least. (optional).
This is, for instance, what is produced when printing a full structure
from a Workspace - AulaWiki Mod - : a coder could grab the code from
AulaWiki Mod as a reference....
In there, the description of the page is set as the Page title (header
2, I think), and the page title is included below for completeness (in
lower font, and with version number next to it)...

edutwo_ws_print_structure4.png

(3) Numbering of headings: somehow, in Workspaces this is handled
internally, and the user/documenter doesn't need to bother with manual
numbering: it's produced also at print time.
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

Example of print structure differences between Tiki's multi-print and
Workspaces print structure:

Print to html "Aula-Wiki Tutorial" from here:
[http://edu.tikiwiki.org/tiki-print_pages.php]

or from here:
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

Well, as you could imagine, some changes to the code to make the work of
documenters a bit easier would be very wellcome also... :-)

(...)

{QUOTE}

!! (2) Update July 20th: Easier solution
Easier solution: Get levels for first heading in each wiki page of the structure not from the content of the page.

^__Example__: a page may start with a "! Title of page" (first level heading), and after that, "!! Subtitle of page" (2nd level heading), ...

Imagine that this page corresponded to "2.3.1 Module whatever" as the level in the table of contents of such structure.

The solution would be then that "!Title of page" (in that page "2.3.1 Module whatever"), when sent to (or fetched by) tiki-print_pages.php as a whole structure, was converted to "!!! Title of page"; and "!! Subtitle of page", should be converted to "!!!! Subtitle of page"..., and this way sequentially for all the title headings on each page from the structure...
^

The procedure below should become a 1-click from wiki (structures) to[http://doc.tikiwiki.org/Tiki19beta.pdf|PDF]. Please see:[http://doc.tikiwiki.org/Printing+the+Documentation|How to produce the .pdf out of the .odt]

-----

Dec 13 2008. Update:
Previous problem is fixed. However, I notice that automatic numbering with heading within a page (!!#, !!!#, ...), should be also considered in the global autonumbering.

Plus width of wide images and tables would be better if not that wide when exported to html (maybe an option), for the case when you plan to import it to OpenOFfice, and they are too wide to the document. Should this be another RFE or bug report?

---
REOPENING BUG
update on Jan. 7th, 2009:
See the other bug report: autonumbering didn't work for me with doc.tw.o/Documentation, even if it did a month ago on another site/structure

Related (and newer) bug report/RFE:
[http://dev.tikiwiki.org/bug2255]

{syntax type="tiki" editor="plain"}
Here:
http://doc.tikiwiki.org/tiki-index.php?page=Structure&structure=Documentation -> structurs is 8.48

Yet, here: http://doc.tikiwiki.org/tiki-index.php?page=Documentation&structure=Documentation , it is 4.31


I don't understand the 8.48

Should be 4.31, no?


See related chat log:
http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2008-12-16,Tue&sel=315#l311

Currently, Tiki allows you to add users to a newsletter by name, email, or an entire group.

I would like to add users based on last login. For example, I want to send a newsletter to all users who have not logged in for 6+ months.

When using the Suggest an FAQ feature, Tiki allows a blank entry of both Question and Answer. This is incorrect. Althought Tiki should allow a blank __answer__, the __question__ field should be required.

It would also be nice to enable a CAPTCHA for anonymous editors.

Please see:
http://www.wikimatrix.org/wiki/feature:CREOLE%20support
http://www.wikicreole.org/wiki/TikiWikiCMSGroupware

Related:
http://dev.tiki.org/Why+Wiki+Syntax+is+Important
http://dev.tiki.org/tiki-index.php?page=2007-07-18+IRC+MediaWiki+discussion&highlight=creole
http://tiki.org/RFCWiki


Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1220|MediaWiki import script]

Support inclusion of media in blogs to provide podcasting, vodcasting, etc.

- Attachment of media files to blog posts
- Association of URLs to other media files on Tiki or elsewhere to blog posts
- Automatic recognition of relevant data from media files using getid3
- Creation of fields in database to store relevant media data
- Creation of enclosure and media XML tags in RSS feed
- Display of media controls in blog entries
- Test using iTunes and iPod, iPodder, Thunderbird, among others

This should be an optional feature, admin through the Blogs Admin panel
Should allow choice of db or file storage, but probably file storage will normally be used, as media files tend to be quite large.

Existing image attachment functionality in blogs will need substantial improvement to support this.

I am often getting:

[i18nwiki@alpha ~]$ cd www
[i18nwiki@alpha www]$ svn up
svn: Working copy 'temp/cache' is missing or not locked
[i18nwiki@alpha www]$


This is caused by something that is destroying some svn system files (presumably trying to clean the cache)

Workaround is to destroy temp and to do svn up

We can now use the login box but it's not very obvious. There should be an icon / button somewere in tiki-adminusers.php

Just after creating a user or adding to a group would be a good time to Switch User and see what (s)he sees.

Hello,

I enabled the option "Detect browser language" in the internationalization module and added the switch_lang module.
But if I'm not logged in and want the change the language using switch_lang it __always__ falls back to my default language.

You can try it at http://series60-remote.sf.net
I had the same problem on http://www.opensourcecms.com/cms/tiki/

This tracker item could not be found

Doing edits in the WYSIWYG editor & switching to 'normal' loses the edits. The remaining content is presented as HTML source. Workaround: turn off option to use either 'normal' or WYSIWYG editor?

Syntax that should work inside a description term (the x in ";x:y") don't. This includes anything in a ':' in it even if it's nested within another syntax structure like a link or table. In a link, it's especially bad, since you can't use ~np~~np~~/np~ to fix it, e.g. you can't fix ~np~((a:b))~/np~. Also, ~np~~~color:x~~~/np~ doesn't work.

~pp~
!!!~np~;a:text~/np~
;a:text
works
%%%%%%%%%%%%
!!!~np~;~~red:a~~:text~/np~
;~~red:a~~:text
looks like ~np~;a:text~/np~
%%%%%%%%%%%%
!!!~np~;((a)):text~/np~
;((a)):text
works
%%%%%%%%%%%%
!!!~np~;((a:b)):text~/np~
;((a:b)):text
looks like ~np~;a:((a:b|b)):text~/np~
%%%%%%%%%%%%
!!!~np~;((a|b:c)):text~/np~
;((a|b:c)):text
looks like ~np~;b:((a|c)):text~/np~
%%%%%%%%%%%%
!!!~np~;((a|~np~b:c~/np~~/np~~np~)):text~/np~
;((a|~np~b:c~/np~)):text
works
%%%%%%%%%%%%
!!!~np~;__a__:text~/np~
;__a__:text
works
%%%%%%%%%%%%
!!!~np~;||a||:text~/np~
;||a||:text
works
%%%%%%%%%%%%
!!!~np~;||a:b||:text~/np~
;||a:b||:text
this just looks strange
~/pp~

I looked in the parser code, and it's pretty obvious why these bugs occur. The parser code, to put it bluntly, sucks. It uses regexps for most parsing instead of a proper context-free parser, so it's bound to have these types of bugs.

Why does this get deleted:

cvs update: warning: templates_c/.cvsignore was lost
U templates_c/.cvsignore
cvs update: warning: templates_c/.htaccess was lost
U templates_c/.htaccess
cvs update: warning: templates_c/README was lost
U templates_c/README
cvs update: warning: templates_c/index.php was lost
U templates_c/index.php



2009-04-17 It's better for branches/3.0 but it still happens somethinges. (ex.: in temp) Need to be able to duplicate and solve.

2009-04-19 Should be ok now.

In 1.9, templates_c existed with some administrative files (templates_c/index.php, etc.):
http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/?pathrev=BRANCH-1-9

Since we moved to SVN, in time for 2.0, this was "lost"
http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/branches/2.0/

This causes that people that install TikiWiki via FTP, from zip file, --need to manually create this folder (useless annoyance)-- Actually, it was created by tiki-install.php but I see no reason not bundle this folder.

People that use sh setup.sh to install are OK because this script creates this directory (and others?)

The "Tiki User Registration Request" email that is sent to admins when a new user registers may not contain enough info for the admin to make a decision as to whether or not to approve the registration. The only link in that email automatically validates the user without any second chance (if the admin thought that after following that link he would be given a chance to review the new user info before validating the unknown user, he will be mistaken).

templates/mail/moderate_validation_mail.tpl should be improved to include any user tracker info that the new user has submitted, or provide a link to view any such user info.

Suggested message if PHP5 is not detected:

^
__TikiWiki 3.0 requires PHP 5.x__

Your currently detected PHP version is: (versionnumber)

Please contact your web host to request an upgrade. If there is no way you can have PHP 5.x, please use Tiki 2.x instead. Some features in Tiki 2.x, such as profiles and TikiTests require PHP5, but all the other hundreds of features work perfectly with PHP 4.1+

For more information:
http://www.gophp5.org/
http://tikiwiki.org/
^



(9:59:42 AM) marclaporte: turning on TikiTests crashed by site :
(9:59:42 AM) marclaporte: Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /home/profiles/public_html/tiki_tests/tikitestslib.php on line 59
(9:59:53 AM) marclaporte: I suspect because I don't have php5
(10:00:01 AM) marclaporte: http://profiles.tikiwiki.org/

This would avoid this type of issue:
http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=6&comments_parentId=21274

Maybe at each release, we could add one test of the DB to see if the most recent sql additions were done.


phplist does this well. Once click and your DB is in the right format.

tiki-admin.php?page=gal tells me if GD or Imagick is installed. Nice.

But sometimes, it's installed, but it doesn't work as it should. To rule out that the problem is with Tiki, here is an example of a simple php to test GD in real life. It would be nice to add to tiki-admin.php?page=gal

{img src=images/code.png}%%% {CODE()}
<?php
header("Content-type: image/png");
$im = @imagecreate(110, 20)
or die("Cannot Initialize new GD image stream");
$background_color = imagecolorallocate($im, 0, 0, 0);
$text_color = imagecolorallocate($im, 233, 14, 91);
imagestring($im, 1, 5, 5, "A Simple Text String", $text_color);
imagepng($im);
imagedestroy($im);
?>
{CODE}

This tracker item could not be found

The aplication menu don´t open when i click the folder.
See at the image in the red circle

{img src= width= height= align= desc= link= }

The directory templates_c does not exist in the 2.2 zip distribution

download from:

http://sourceforge.net/project/showfiles.php?group_id=64258&package_id=266122

file:

tikiwiki-2.2.zip

In certain instances when editing a page through the text editor (or creating a new blog post), with the wysiwyg-available available (though hidden) the smilies field is not displayed.

The problem is probably due to the fact that the variable $wysiwyg contains an 'n' if the editor is hidden while in some instances the value is NULL. This is probably because if the wysiwyg feature in admin-features is disabled then the $wysiwyg value is NULL, but if it is enabled but hidden the value is 'n'.

There is a conditional in templates/tiki-editpage.tpl that does not take this into account.

(The problem may be present in other versions as well)