Category: 6.x
Show subcategories objects| Name | Type |
|---|---|
| Wiki slideshow viewing mode (Slides) shows fragments of plugins | tracker item |
|
Wiki text returned from plugn not parsed
{syntax type="tiki" editor="plain"} __Tiki:__ 6.1 __Firefox:__ Wiki text returned by the SQL plugin is not translated. I used the "Quote" plugin to verify if this problem exists for all plugins returning Wiki text and the value translated as specified in the data passed. We make fairly extensive use of the SQL plugin on our internal department site. A technique for implementing this plugin we use is to enclose the return value of a column in double parenthesis. This enables us to have a web page reference for each of the returned rows. This technique is used in several circumstances. One is that we select from our database stored information on hundreds of servers making the server name a link to a detailed info page. The example below is used to link to project detail pages describing individual active projects. {CODE(caption="Example SQL",wrap="0")} select concat( '((', p.project_name, '))' ) as "Project Name", u.user_username as "Project Owner", tdv.value as "Project Status" from projects p, departments d, project_departments pd, tsi_dp_valsets tdv, users u where p.project_id = pd.project_id and pd.department_id = d.dept_id and d.dept_name = 'TSI-KPHC' and u.user_id = p.project_owner and tdv.ID = p.project_status and tdv.value != 'Archived' and tdv.value != 'Complete' order by tdv.value; {CODE} This issue is not restricted to link specifications as bold (double underscores) no longer work when returned by SQL either. I have rated this a "9" strictly from a personal importance perspective and not as a definition of impact to the overall Tiki project. The customers of our department rely on these returned links for information and updates. I have been all through the Administrative areas hoping to find a feature flag to turn on wiki text parsing of plugins (before trying the above referenced "Quote test") and am also unable to find such a flag specific to the SQL plugin. --Steve |
tracker item |
|
Wiki-links and non-latin characters
__problem __with Russian (and, as I understood, any non-English character language) wiki-links in CKE Editor (and plugins): 1. Let's create wiki page named "Фичи" (copy-paste, hope it'll be work) 2. Create page with any name e.g. test with wiki-link to a first page ("Фичи"). 3. Link is broken. becouse on the stage of convertation from wiki-link to CKE URL something goes wrong and if You click on this link and choose "Edit Link" you'll see "tiki-index.php?page=äøÃÂø" 3.1 Yes, link is broken: Page not found äøÃÂø ---- Hint: without WYSIWYG editor all will be ok. No broken links with any symbols. __Why priority is high?__ -becouse we can't create ANY wiki-links from CKE-editor if wiki page named with non-Latin leters. p.s. double-checked here http://php.opensourcecms.com/scripts/details.php?scriptid=63 with WYSIWYG_6x profile. tags: utf-8, russian, link, wiki |
tracker item |
|
WikiWords don't work
Typing a WikiWord does not result in a wiki link. You must enclose the word in (()), even if the feature is turned on. |
tracker item |
|
Wrong link encoding in Wysiwyg editor
{syntax type="tiki" editor="plain"} When I create a link to a Wiki page, the editor changes the reference of the link until the fourth time when I edit the page, but this is not a problem. The problem occurs when the link points to a wiki that has a special character, for example - cabeçalho - which means header (in Portuguese from Brazil), since the editor corrupts the link and it crashes. Here I have an example. The link should point to the wiki - Projeto de Pesquisa Social: Quem somos nós ? Proeja 2010 - is corrupted by the editor and points for - Projeto+Pesquisa+Social:+Quem+somos+n%C3%83%C3%83%C3%83%C3%83%C3%83%C3%82%C2%B3s?+Proeja+2010 - Here we have a wiki page as an example: http://www.biblioteca.ifc-camboriu.edu.br/criacitec/tiki-index.php?page=Example |
tracker item |
|
WYSIWYG and International character problem in links
Problem: Corrupted URLs when linking pages using international characters in the page name. It works when the link is first saved, but a reload and a subsequent saved will corrupt the URL. The same problem occurs in 6.x 7.x and 8.0 SVN. In these tests the WYSIWYG editor is used. (I have formatted the output a little for better readability) --- Test using latest 8.0 SVN version --- 1. Create the page "ÆØÅ page" 2. Create the page "MyLinkPage" 3. Add a link to "ÆØÅ page" on MyLinkPage, using the link tool in the menu 4. Save and exit editor Content of MyLinkPage (wiki source view) <p><a class="wiki" href="tiki-index.php?page=%C6%D8%C5+page">ÆØÅ page</a></p> Content of MyLinkPage in the database (tiki_pages.data) '<p><a class="wiki" href="tiki-index.php?page=%C6%D8%C5+page">ÆØÅ page</a></p>' 5. Edit MyLinkPage again <<<<<<<<<<<<< URL is no longer encoded, but the page name is Content of MyLinkPage (WYSIWYG source view) <p><a class="wiki" href="tiki-index.php?page=ÆØÅ+page">ÆØÅ page</a></p> 6. Add some text in the WYSIWYG editor added some text 8. Save and exit editor <<<<<<<<<<<<<<<< CONTENT HAS A CORRUPTED URL Content of MyLinkPage (wiki source view) <p><a class="wiki" href="tiki-index.php?page=%C3%86%C3%98%C3%85+page">ÆØÅ page</a></p> <p>added some text</p> Content of MyLinkPage in the database (tiki_pages.data) '<p><a class="wiki" href="tiki-index.php?page=%C3%86%C3%98%C3%85+page">ÆØÅ page</a></p> <p>added some text</p> ' ---- end of test ---- As far as I can see, the problem occurs when the WYSIWYG editor loads the page (it works the first time, because the links are not loaded, only saved). I tried a similar test using the wiki editor The wiki editor stores the wiki content. Thus database the content is: ((ÆØÅ page|ÆØÅ page)) The wiki editor has no problems. A variation is loading the page using the wiki editor, then switching to the WYSIWYG editor The source in WYSIWYG is afterwards <p><a class="wiki" href="tiki-index.php?page=Ã?Ã?Ã?+page" title="ÆØÅ page">ÆØÅ page</a><br /> added some text</p> thus also corrupted the URL. |
tracker item |
|
Wysiwyg Image Plugin Editor in IE7 erases image on insert
Only happens in real IE7. IE8 in IE7 compatibility mode does not have this problem. Basically an attempt to edit the image plugin parameters followed by clicking on "Insert" results in a JS error "Invalid argument" at line 4929 of lib/jquery/jquery.js (r30367). If you continue through the error, the image disappears. {CODE()} clean: .... ..... if ( fragment ) { ....... if ( ret[i].nodeType === 1 ) { ret.splice.apply( ret, [i + 1, 0].concat(jQuery.makeArray(ret[i].getElementsByTagName("script"))) ); } fragment.appendChild( ret[i] ); // this is line 4929 {CODE} If the image is at the end of a paragraph (or on a line of it's own) resulting in the following cases, you will have the problem. {CODE()} <p> Paragraph text{img fileId="10" rel="box[g]" imalign="left"}</p> {CODE} {CODE()} <p> {img fileId="10" rel="box[g]" imalign="left"}</p> {CODE} If you instead have text after the image, the problem does not appear. For example, the following are both OK. {CODE()} <p> Paragraph text{img fileId="10" rel="box[g]" imalign="left"}Paragraph Text</p> {CODE} {CODE()} <p> {img fileId="10" rel="box[g]" imalign="left"}Paragraph Text</p> {CODE} I suspect (just a theory) maybe the plugin replacing procedure is wiping out the closing para tag leading to malformed HTML that IE7 does not like. A search on the web on similar errors in relation to Jquery show that IE7 is very sensitive to unclosed tags or malformed HTML in inserted text. |
tracker item |
|
WYSIWYG_6x - Anchor flag not saving
{syntax type="tiki" editor="plain"} We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database. This bug is across all browsers. Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins Wiki Paragraph formatting (ON, however default: off) ...but still create line breaks within paragraphs (on) HTML Purifier (on) Wiki Allow HTML (on, however default: off) WYSIWYG Content is parsed like wiki page (on) Content is partially wiki parsed (off) Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it. I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation. I have tried in both IE 8 and FF 3.6 with the same result. Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system. May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499] |
tracker item |
|
WYSIWYG_6x - Edit Section buttons return blank page
{syntax type="tiki" editor="plain"} We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins Wiki Paragraph formatting (ON, however default: off) ...but still create line breaks within paragraphs (on) HTML Purifier (on) Wiki Allow HTML (on, however default: off) WYSIWYG Content is parsed like wiki page (on) Content is partially wiki parsed (off) Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section. Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button. |
tracker item |
|
WYSIWYG_6x - Formatting breaks "header" status
{syntax type="tiki" editor="plain"} We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins Wiki Paragraph formatting (ON, however default: off) ...but still create line breaks within paragraphs (on) HTML Purifier (on) Wiki Allow HTML (on, however default: off) WYSIWYG Content is parsed like wiki page (on) Content is partially wiki parsed (off) Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not format the header (color it red) without breaking the "header" status. Currently we have a page with a ~np~{maketoc}~/np~ at the top and a bunch of h1, h2, h3 headers. We wanted to make the text color red for one of the h1 titles so it was more visible to users. Once we did this in the WYSIWYG editor, the header is no longer listed in the maketoc AND the Edit Section button is gone next to the header text. This ''may'' be associated with another bug [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3763]. |
tracker item |
|
WYSIWYG_6x - List spacing inconsistent
{syntax type="tiki" editor="plain"} We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins Wiki Paragraph formatting (ON, however default: off) ...but still create line breaks within paragraphs (on) HTML Purifier (on) Wiki Allow HTML (on, however default: off) WYSIWYG Content is parsed like wiki page (on) Content is partially wiki parsed (off) Use Wiki syntax in WYSIWYG (off){CODE}%%% the lists (numbered and unordered) have irregular spacing between lines. Edited in Wiki normal and WYSIWYG Source modes work fine. To reproduce create the following structure in a WYSIWYG editor{CODE()}*blah zaa zaa *This is a list **now indenting the list **blah *back out **back in ***really far in *all the way out{CODE} %%% this example displays for us as {CODE()} blah zaa zaa This is a list now indenting the list blah back out back in really far in all the way out {CODE} %%% Sometimes there is a break, other times there is not. If I Preview while editing it looks fine. If I edit the HTML via the Source WYSIWYG view and save then it looks fine until I save it in WYSIWYG mode again. |
tracker item |
|
WYSIWYG_6x inserts !'s into text before any text formatted as a header, saved, then edited again
{syntax type="tiki" editor="plain"} When editing or creating a page using the WYSIWYG_6x editor, setting any text as a header then saving the file works correctly, however if the page is edited again, the WYSIWYG editor inserts a ! before or sometimes after the text you decided to format as a header. Looking at the source, it appears that it is inserting the following into the page: <p> !</p> Attempting to remove it by deleting the ! in the WYSIWYG editor just results in it showing up again, either immediately after saving or on the next edit of the page. This results in people not wanting to use the header feature or finding other workarounds such as larger font size. |
tracker item |
|
xajax Javascript component could not be included
{syntax type="tiki" editor="plain"} The following error occurs always when i follow a link from tiki-searchresults.php and the search string contained a slash (/). E.g. searching for 343/07 reveals the correct article. On tiki-searchresults.php the string "343/07" is highlighted (tiki-searchresults.php?highlight=343%2F07&where=pages&search=Los). Following the link (articleXXXX&highlight=343/07) I get this error message: ^Error: the xajax Javascript Component could not be included. Perhaps the URL is incorrect? ur The problem is caused by the slash in (articleXXXX&highlight=343__/__07). If I change the url manually to "articleXXXX&highlight=343" everything's fine. |
tracker item |
|
User must have global permission tiki_p_edit for adding a new page in categorized structure also he has it in the categorie.
{syntax type="tiki" editor="plain"} I defined a structure Helpdesk FAQ and a categorie Helpdesk. Now I give a group Helpdeskadmin the permission tiki_p_edit (and a lot of others). If a helpdeskadmin trys to add a page with the button on the top of the wikipage with over the toc, the message "You do not have permission to edit this page." appears. The problem seems to be the following permission test in tiki-editpage.php: // Permissions $tikilib->get_perm_object($page, 'wiki page', $info, true); if ($tiki_p_edit !== 'y') { [...] $smarty->assign('errortype', 401); $smarty->assign('msg', tra("You do not have permission to edit this page.")); $smarty->display("error.tpl"); die; } If I give the permission tiki_p_edit to the group, the helpdeskadmin comes to the wysiwyg-edit-page, also he gets a message like the page must have a categorie. I didn't analyzed that yet. |
tracker item |
|
5.x -> 6.1 regression: Users Information Tracker Fields Asked at Registration Time
{syntax type="tiki" editor="plain"} Does the "Users Information Tracker Fields Asked at Registration Time" work for someone in 6.1? it used to work in 5.x. not pretty. This feature was not particularly important if the trackers with registration="y" would work nicely. Read more here. [http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-01-08,Sat&sel=52#l48] |
tracker item |
|
domain redirect from *.tikiwiki.org to *.tiki.org is not working
{img fileId="270"} Visit these pages to see for yourself: http://info.tikiwiki.org/Hosting (6.x) http://profiles.tikiwiki.org/Profiles_in_installer (9.x) http://dev.tikiwiki.org/Tiki13 (12.x) It should be a redirect 301. And needs to work for 6.x, 9.x and 12.x This worked when the feature was introduced so some other fix / enhancement must have broken it. This is especially not good because in this version the ((canonical)) link is just relative and thus, we have two canonicals for same page... If you go to front page, it redirects OK http://info.tikiwiki.org (6.x) http://profiles.tikiwiki.org (9.x) http://dev.tikiwiki.org (12.x) |
tracker item |
|
6.x: accepting a structure sent between tikis fails (column 'page_alias' cannot be null)
After sending a structure between 2 tiki sites (using the send pages features between tikis, xmlrpc, etc), once I clicked on the button to accept the received structure in the target tiki site, I got this error: {CODE()} Column 'page_alias' cannot be null The query was: insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`, `structure_id`) values(?,?,?,?,?) Values: 0 70 1 0 The built query was likely: insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`, `structure_id`) values('0','70',NULL,'1','0') {CODE} Both tiki sites are running recent proposals_6x The url on the target tiki was: tiki-received_pages.php?offset=0&sort_mode=receivedDate_desc&accept=1 |
tracker item |
|
6x: apparently unreliable tracker item history: works in some sites, but not on others
Tracker item history seems to be unreliable: it works for me on some 6x sites but I haven't been able to make it work in a local 6x or proposals_6x . # I create a tracker item # I edit the tracker item again, changing some fields (1 text area, and 2 text fields ) and save changes # refresh the tiki-tracker_view_history.php?itemId=1 page but I see nothing there |
tracker item |
|
6x: Webmail account can't be deleted (& unreliable behavior)
((GroupMail)) is not working for me any more since I updated a site to 6.x from 4.x In 4.x it was working me (I created most of the documentation in doc:((doc:Groupmail)) Maybe that's because Webmail is not working either...? What I did: * installed a new tiki proposals/6x tiki site in localhost * added ajax_xajax feature to the groupmail profile (it was missing) * applied Groupmail profile * followed instructions to setup a new group (web)mail account * the module groupmail is spinning all the time, and no messages are shown * I've double checked that the user and pass info for that email account are all right I also applied that profile on a remote server (a production site) and no luck either. No email is fetched. I checked the webemail account (by means of other webmail software) and I confirm that it has plenty of read email, and 2 new messages pending to be read. --- Update: Weird, after I tried to unsuccessfully delete that account in the remote (production) server, it seems that webmail started to work! :-/ Well, it looks boggy to me, or at least, for sure it's been unrealiable behavior! At elast, for sure tehre is a bug at removing a webmail account: which is not removed (even if you ckick again at the confirmation step, the account is still there) |
tracker item |
|
Action Popup in File Galleries not working
{syntax type="tiki" editor="plain"} I upgraded an old tiki 4 install to 6.0. In filegalleries I did not get the popup when I clicked on the action icon. Nothing happened. => I could not update a file. I found out that it worked when I set "Use CDN for Java..." to GOOGLE in Performance settings. |
tracker item |
|
Add a select box to monitor each own's forum post, comments or tracker submission or wiki page at post time
I've been thinking for ages that this kind of option is REALLY needed, and I thought it should not be much coding effort: Automonitoring each own's posts, through either: # Add a select box to monitor each own's forum post or tracker submission at post time, in a "per forum post or tracker item insertion" basis, or # with a user preference for all forums, or all trackers, blogs, etc.. --- Still needed... |
tracker item |
|
add group watch to articles
Add group watch to articles This way we could also have all users informed about comunity news , etc. in tiki sites. In fact, the best option would be what it's done with newsletters: subscribe that bunch of users from a group, and let them unsubscribe it they wish and when they wish, without admin action. But if no action is done, they all get the copy of the article at their email, etc. |
tracker item |
|
add page to structure button regression
{syntax type="tiki" editor="plain"} |
tracker item |
|
Admin setting Log In, setting still apply on uncheck section
On the Admin section -> Log In -> Authentication method: Tiki The setting Users can register is uncheck. All the sub setting are hidden but some setting seams to still applied. Example : If "Validate new user registrations by email" is checked the user will be forced to validate his email. |
tracker item |
|
Admin topics -> editing a topic show issue with the Email fields
When creating a topic in admin topic (tiki-admin_topics.php) i have 2 fields to fill: Topic Name Upload Image Only name is mandatory and saving is ok. If i want to edit the created topic to modify it i see a third field appearing: Add Notification Email. If i save without giving an email i got the following error : Invalid email. I can't save. Best evasion course is to close or jump back from this page. I don't recall having set a feature or an option that force emails for topic article notifications. There is no reason why i should be forced to add an email ONLY on edit (if a feature were set for a mandatory email address) and the error message (if he is linked to a feature) should be more explicit. |
tracker item |
# log out
# click on the Slides button under HomePage content; tiki-slideshow.php?page=HomePage&slide=1 displays fragments of plugins as ~np~{DIV}~/np~, ~np~{ELSE}~/np~ and ~np~{GROUP}~/np~ (in other words it doesn't parse the plugins properly)