Category: Closed - Completed

Many banner advertisers use a javascript for banner adverting. Currently, there is no way to add a JS-based banner.

If I have a login box module, and I visit tiki-login_scr.php, I get two places to login

Same thing with error pages which offer to login.

In the early days of TikiWiki, we used a bunch of modules (last_modified_wiki_pages, last_articles, Last this, Last that, etc.) to show recent changes to visitors. We ended up with many modules and it was cluttered.

All this became a lot better once the "Since your last visit" module came around to adding all the features. As a bonus, it checks permissions and shows the information since the user's last login. Very sweet.

Now, I am hoping to get to the same result for the many edit/input boxes.

In version 3.0, the quick_edit module checks (with Ajax) for names of existing wiki pages to edit. This avoids duplication. Great stuff. Wikipedia does something similar when you are searching for a page name.


I almost always have the search box on.

However, I also add "search page name" because the general search engine may not return the page I am looking for as the search result.

Here is an idea:

A new module which combines three modules:
search_wiki_page
search_new
quick_edit

See top right of http://moinmo.in/ for an example.

The action buttons are grayed out until text is entered in the text box. -> Very nice


Button should be WYSIWYCA


See top-right search box at:
http://www.ohloh.net/projects/tikiwiki
http://www.wikicreole.org/



__Alternatively, we could combine search page name and search text, and in the search results, we would first show pages names, and then, search text. This involves more work, but could be better for the end user UI.__

^I think the existing layout for the search top right in TW is fundamentally good. A text box, then a drop-down then a button. Why because the drop down is more future proof than any of the layouts from the other sites you reference.

If we make the contents of the drop down easy to customise or at the very least document how to add to it. For example the CRM function could add items to the drop down for "Contacts" and "Accounts", webmail could add "Mail Messages" and so on.

I do agree the wikipage create/edit module should be included in the top right search function.

I think this is an example of where considering the future openness of the solution would be very important - MatWho^

{THUMB(id=98)}{THUMB}

We were trying to have the new antibot captcha working in a Tiki site based on Tiki trunk (during TikiFestBarcelona2 - mid July 2010), were a user tracker was set to collect more information from users at registration time.

when we enabled zend new antibot-captcha , no antibot code was shown at registration time, because there seems to be some conflict with the user tracker.
Once the user tracker was disabled, the antibot-captcha was shown properly, etc.

----
Update: disaled the new zend antibot catpcha, in order to use the former simple captchaimage, but that one is not working either, if user tracker is on.

Just compare Greek characters (απόσπασμα) on these 2 sites:
http://tiki.org/forumthread52617
http://next.tiki.org/forumthread52617

I (Marc Laporte) suspect something in the pre-dogfood server upgrade script. Maybe UTF-8 related. See [item5337]

To reproduce, edit a bug and look at the category selector (ex.: Feature)

In both the object and category permission admin screens the URL for the Back btn at the top left of screen is not being properly formed

Looking at tiki-objectpermissions.tpl line 6 the variable $referer must already have the full URL and then the URL root is being prepended again

This bug can be seen in the current dev site

seems to be fixed now {sign user="eromneg" datetime="2014-07-21T12:15:39+00:00"}

On a new 1.10 installation...

When logging in as the ADMIN for the first time, the Change Password Enforced page appears (requiring new admins to select a new password). The OLD PASSWORD field should be maintained (pre-filled) with the existing admins password (by default: ADMIN). This __used__ to be the case in 1.9.

Pre-populate the OLD PASSWORD field with the user's existing password. This field should be disabled, so the user cannot change it.

We are documenting some ((info:Use Cases)) which will become profiles. To be able to developer/test/improve these profiles, we would need a site like [http://www.opensourcecms.com/index.php?option=com_content&task=view&id=180|Open Source CMS] but for all profiles. This site only shows one profile.

These 20+ demo sites would provide admin access to easily test any profile. It would encourage people to generate and improve various profiles as well.

Related:
((Profile Manager))
((TRIM))

Has anyone written a module to integrate PayPal's ecommerce capabilities into TikiWIki?

Should be done through a module and several plugins (ADD_TO_CART, SHOWCARTCONTENTS, CHECKOUT etc)...

Oh, on that one, I would love to have a plugin that invalidates the cache to make sure that inside a cached website there are pages that are always rendered fresh...


Related:
*[wish1808|Shopping Cart / ecommerce / online orders]
*((shopping cart))

When a page is restricted by permissions, this page cannot be exported to pdf using the pdf icon.
The result is a pdf that contains the message "You do not have the permission to view that page....".
The reason for that is that the pdf export contains NO mechanism to pass the authentication of the logged-in user to the pdf tool. So the pdf tool (i.e. wkhtml2pdf) calls the page in question as an un-authenticated user.

Update:
Main issue fixed. Restricted pages require token authentication enabled to be exported to pdf.
Feature: "auth_token_access".

Note: If the page acts as a template for tracker input - access is still debied. This might be an issue with the "auth_token_access" feature itself and should be a new bug report bc it might effect other areas as well.

There was a missing check to make sure users had the permission to switch permission.

This commit was to address this:
http://sourceforge.net/p/tikiwiki/code/46963

However, now, it's not possible for anonymous uses to switch perspectives, even if they have tiki_p_perspective_view

Noob here enjoying the site, enjoying the software and finding my way around. Thank you.

It means spending a *lot* of time at the Tiki sites.

I get the message already about the dogfood. Cool.

But every day, every page load, I must dismiss this notice to uncover what is underneath. Or scroll the viewport out from under it.

It is located on top of the navigation.

Can we not have it fixed in the page above the navigation, or permanently dismissable once logged in, or ...?

Can we just use the site now, and stop swatting at the javascript? :)

I'm just setting up svn etc now. And wouldn't have the balls to make such a visible change right off the hop anyway. It's not real important obviously. But if somebody is there and knows and can do, it would make surfing the sites more pleasant...

Cheers!!

When I place this on a Wiki page:
{img src=images/code.png}%%% {CODE()} {agentinfo} {CODE}

I get this error message:

"Fatal error: Call to a member function get_ip_address() on a non-object in root\lib\wiki-plugins\wikiplugin_agentinfo.php on line 33"

Plugin Image Annotation is broken. https://doc.tiki.org/PluginAnnotation
#Annotation zone is offset (away from the mouse selected zone)
#Annotation link is not displayed
#Buttons on the note look bad


Here an example
{annotation src="display1017" width="400" height="500"}

The information specified in the info parameter (like "hits" or "user") is not discplsyed.

PluginAnnotation missplaces boxes in Tiki14 compared to Tiki12.

Issue reproduced here:
https://doc.tiki.org/PluginAnnotation+example

Log in as Registered, and try to add a box somewhere in the image, you will see the red box drown somewhere else (missplaced to the right of your cursor).

See it working as expected in Tiki12 (reproduced in a show instance here):
http://xavi-9794-5777.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

The iframe plugin page on tiki.org needs its own plugin approved:

http://doc.tiki.org/tiki-index.php?page=PluginIframe#Example

{flash type="url" movie="display292" width="589" height="633"}

Profiles wiki handler: translations param doesn't work. To reproduce, see and apply profile: http://profiles.tiki.org/Consensus+Forums

This page:
http://xavi-9794-5371.show.tikiwiki.org/tiki-index.php?page=Instructions+for+the+Consensus+Forums

should be in the same trnaslation set as the equivalent Spanish one:
http://xavi-9794-5371.show.tikiwiki.org/tiki-index.php?page=Instrucciones+de+los+Foros+de+Consenso

This is how the pages are defined in the profile decalaration:
{CODE()}
objects:
-
type: wiki_page
ref: consensus_forums_include
data:
name: Instructions for the Consensus Forums
description: Instructions on how to use forums to help users seek consensus on discussion threads
lang: en
mode: create_or_update
translations: consensus_forums_es_include
content: wikicontent:Consensus_Forums_Instructions
-
type: wiki_page
ref: consensus_forums_es_include
data:
name: Instrucciones de los Foros de Consenso
description: Instrucciones sobre como users los foros para ayudar a los usuarios a buscar consensos en cada hilos de debate
lang: es
mode: create_or_update
translations: consensus_forums_include
content: wikicontent:Consensus_Forums_Instrucciones
{CODE}

However, the "translations" keyword doesn't seem to take effect.

These regex expressions could be shared in a wiki page.

Ex.: ZIP code, Postal Code, Phone number, etc

Idea by Fernando Galandrini

using www.domain.com vs domain.com and it will not keep you logged in.

Plus, having www is no longer relevant nowadays


http://www.fabianlim.name/redirecting-non-www-domain-to-www-using-htaccess
http://arjaneising.nl/wp-content/uploads/htaccess-www.txt

{CODE(caption="Jonny says")}Finally - Marc, did you crack the www url problem? As you said, it would be nice to have as a pref in Tiki and i think the only way to do it for all cases (subdomains, subdirectories etc) is in PHP. For now we could just add it to local.php - stuff like:

if (strpos($_SERVER['HTTP_HOST'], 'www') === 0) {
// do stuff...{CODE}



Related:
{wish id=1611}

Updated from 5.1 to 7.0, now RSS Feeds not working. Also not working with 7.1 RC1.
Chrome browser reports HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.
No page displaying in firefox. Tested on Blogs and articles, both have same error. PHP-XML is installed (report of this error in community section discussed PHP-XML as being the solution)

This is RSS feed
http://www.bookkeepersireland.com/tikiwiki/tiki-blogs_rss.php?ver=2

[https://wiki.php.net/rfc/optimizerplus|Optimizer+ will be integrated into PHP 5.5.0]

So
1- We want this in the dashboard like APC and Xcache
2- We want to make sure it works with tiki-monitor.php -> http://sourceforge.net/p/tikiwiki/code/48039


OPCache:
http://php.net/manual/en/book.opcache.php

OpCache status from Rasmus Lerdorf:
https://github.com/rlerdorf/opcache-status

Related:
http://rtcamp.com/tutorials/php/zend-opcache/

Important commits:
http://sourceforge.net/p/tikiwiki/code/27831
http://sourceforge.net/p/tikiwiki/code/27829

ex.:

# Redirects
# This is useful if you are migrating from an old site, and you want the old URLs to still work.
# Just uncomment and edit the line below.
Redirect 301 /oldpage.html /tiki-index.php?page=newpage