dokuwiki / dokuwiki Goto Github PK

First i had installed(if i remember it right) the linksuggest Plugin via the Extension Manager. Fine sofar. This is done by url given at plugin page [1].

Now i installed it from a different url [2] than provided at plugin page. (the url of master branch zip)

When looking at the info section, it still shows that my download url is the link from the repository.

When i uninstall, and manual install the plugin from url [2] again, the wrong download url is shown again.

[1] https://github.com/lisps/plugin-linksuggest/releases/download/2014-02-18/linksuggest.zip
[2] https://github.com/lisps/plugin-linksuggest/archive/master.zip

A few plugins like the outliner plugin use dl/dd/dt tags for formatting their content. Their CSS may clash with the CSS of code/file.

I found the indentation of the outliner plugin to be such a case. The fix is to explicitly set the padding of the container to zero:

.dokuwiki dl.code dd, .dokuwiki dl.file dd {
    padding: 0px;
}

The valid_input_set() function has a weird set of parameters:

 * @param string $param        The name of the parameter
 * @param array  $valid_values A set of valid values; Optionally a default may
 *                             be marked by the key “default”.
 * @param array  $array        The array containing the value (typically $_POST
 *                             or $_GET)
 * @param string $exc          The text of the raised exception

• I don't like the mixing of numbered indexes and the 'default' key in $valid_values
• I don't like the passing of an $array to be checked for a given $key

I thinks this kind of feature might be a good candidate to incorporate into the $INPUT handler.

Alternatively I'd prefer the following signature:

@param string $value  The value to be checked
@param array $valid_values A set of valid values
@param string $default The default to be returned if the passed $value isn't valid

Opinions?

For use of DW as CMS it should be possible to configure the checkbox "Minor changes" on the editor page to be checked by default.

This will avoid subscribers to be alarmed on small changes, where the editor forgot to check the box after fixing typos.

Since "Binky" and still with "Ponder Stibbons" my wiki shows strange reference numbers for the footnotes. The first footnote does not start with 1 but with a random number. The following footnotes are normally +1. But not always the footnotes start with a wrong number.

An example where footnotes start at 1:
https://www.altaplana.be/dictionary/les-ponts-de-sarajevo

Some wrong examples:

Start at 26:
https://www.altaplana.be/dictionary/les_coulisses_des_cites_obscures

Start at 36:
https://www.altaplana.be/dictionary/durieux_laurent

Start at 21:
https://www.altaplana.be/albums/revoir_paris

DokuWiki version: "Ponder Stibbons"
OS: CentOS release 6.5
Webserver and version: Apache/2.2.15 & PHP 5.4.28
Web browser and version: Chrome 34

As suggested in f87b5db#commitcomment-5583295

In configuration manager, in the area 'advanced' the option 'updatecheck' is disabled - I cannot toggle the checkbox/flag. all other options are enabled.
The box is highlighted in light red.
Can't find out why this is not allowing input.
This option is described as "Automatisch auf Updates und Sicherheitswarnungen prüfen? DokuWiki muss sich dafür mit update.dokuwiki.org verbinden."

This issue occurs with latest master branch of dokuwiki.

We have just upgraded to Binky, but i think this issue is not new. Lets go:

Steps to reproduce:

1. Try to create or edit a page
2. When the editor shows up, click the wiki:syntax link

Expected:

1. Go to page wiki:syntax and show the contents

Instead, i got:

1. Only a blank page, with no side buttons (edit, revisions, back to top, etc.)

I've checked:

• data/pages/wiki/syntax.txt is there and has content
• owner, group and file permissions are ok

Thus i don't know what is happening to this page. Any tips or help will be very appreciated.

I have just updated to the new version of Dokuwiki on an installation that has not been updated in quite a while and I get the error message for one plugin:

getInfo() not implemented in syntax_plugin_pagelist and ...lib/plugins//pagelist/plugin.info.txt not found. This is a bug in the pagelist plugin and should be reported to the plugin author.

This message will probably go away when updating the plugin, so the message should mention that, otherwise a plugin author may get messages about old version of their plugin.

(btw, I like the new plugin manager much better than the old one)

the function should handle @ALL in the given member list

Since "Binky" some 'onoff' options for plugins are set permanently on.

This problem occurs when a configuration change is made and the plugin or template has options that have default values of true or false. This does not happen if the default value is 1 or 0. This does also not happen when the value has previously been changed.

The problem is caused when the values are set in class setting_onoff in config/settings/config.class.php. The lack of a local value causes the default value to be used. Prior to "Binky" this was set to the value true of false. Since "Binky this is set to the text 'true' or 'false'. As this is a text string it is interpreted as true and the resultant field is marked to checked. Once the configuration is saved the value is changed.

This problem does not show until the configuration has been changed and so will not be noticed unless and until a change is made.

I have made a temporary bypass before $value is assigned as follows:

if ($this->_default == 'true')
$this->_default = true;
else if ($this->_default == 'false')
$this->_default = false;

This needs to be corrected where $this->_default is set in the first place.

There is also an error in the assignment to $input where the value is always set to "1" rather than to $value, but changing this does not appear to have any effect. It would seem that the 'checked' state is used instead.

php function hp_logo_guid() is removed from PHP version 5.5.0 and syntax page is blank now. Of course only if "Allow embedded PHP" is activated.
http://at2.php.net/php_logo_guid

If a page has exactly one revision (i.e. it was just created and never edited), the wiki.getPageVersions call does not return any versions.

I think a good way to keep a Wiki clean is to be able to safely rename pages also after long usage when new sections and stuff is added to the WiKi. This should be a legacy feature of the software because of the complexity of resolving and updating links.

Even though both the _video and _audio-functions in the xhtml renderer use a $cache variable, this variable is undefined which means that the cache parameter for audio and video fetching can't be controlled.

An additional parameter should be added to both functions in order to pass the cache parameter.

The request
"GET /doku.php?id= :euleninfos:eulenliteratur:eulenzeitschriften:eulenrundblick:eulenrundblick-39 HTTP/1.1"
gets logged as
"GET startseite :euleninfos:eulenliteratur:eulenzeitschriften:eulenrundblick:eulenrundblick-39 HTTP/1.1"

(Seemed to be a bot, that requested "/doku.php?id= :euleninfos:..." with space following =)

One feature of the old Plugin Manager plugin I found very useful was its links to a plugin's page on https://www.dokuwiki.org/
I think it would be useful for the drop-down information in the Extension Manager to include a reference to these pages.
e.g. https://www.dokuwiki.org/plugin:extension

#169
Has some styling, which is added to the 'dokuwiki' template. What about moving this styling to some core css styles?

If you enter, e.g. "Anika Henke" (way, she has published enough templates and plugins to stage in a test here) in the search field of "Search and Install" then any hit after the first hit that is a template has a "Doku" link to "https://www.dokuwiki.org/template:..." - even if it is a plugin (screenshot / Bugs link / keywords / install url are not affected).
The same happens if you click on "Anika Henke" under "Installed Plugins" and "Installed Templates" (which calls "Search and Install" with "authorid:4933823dc5f71300a20a506869fcf4d9").

I installed a template using the extension manager.
(https://www.dokuwiki.org/template:greensteel)

It was installed into the current template in use, eg dokuwiki.

In the file template.info.txt the field base has parameter : dokuwiki.
This is wrong, should be : greensteel

I don't want this kind of trouble and i think this is not meant to happen.

Maybe check for loading in existing template and ad a warning.

The S5 plugin is not findable with the new extension manager. I guess that's because the search term is too short?
It can be installed by adding the URL, but it should be possible to find it in the first place. Especially if this is the way most people will install plugins in the future.

The authad plugin pages needs info on how to configure dokuwiki with multiple domains and servers

the manager.dat contains

• a (install)download url
• and some dates

The Extension manager seems to not set the manager.dat files in the plugin directories anymore. Therefore this download url info is lost.

• When manager.dat exist, that download url is used to check if an url is changed. A wanted feature.
• now the Extension manager keeps comparing with the url available via manager.dat, but after update the new url is not added, so the warning don't vanish.

(Probably #627 is a bit related)

1) helper_plugin_extension_extension_test::testExtensionParameters
Failed asserting that false is true.
/home/travis/build/splitbrain/dokuwiki/lib/plugins/extension/_test/extension.test.php:71

line 71 is a check for is_bundled. I don't see how this can sometimes fail and sometimes not. @michitux can you have a look?

Table grid doesn't always display properly in Firefox 29.0.1. This varies by Table (sometimes when 5 or more rows are created - other times when 4 or more rows are created). The below table was created using standard DokuWiki syntax (NO HTML or CSS).

Here is what it looks like using Firefox 29.0.1:

Here is what it should look like (screenshot taken in Safari 7.0.3):

For some reason /lib/exe/jquery.min.map is always called. I thought this should have been fixed with a335e2e but at least on dokuwiki.org it is still causing problems. I just discovered that even with that change, it is still causing that "file" to load. Although in this case it causes a 200 because it interprets that as the page :lib_exe_jquery.min.map.
In other cases it causes 404s and redirect loops. Although I don't think the user in this example uses a DokuWiki version with that fix: https://forum.dokuwiki.org/thread/10758

Hi dokuwiki team,

I'm trying to update form Binky to Ponder Stibbons on a RHEL5 server.

I've got the following error:
[error] PHP Warning: Wrong parameter count for session_set_cookie_params() in /usr/local/dokuwiki-2014-05-06/inc/init.php on line 153, referer: https://server/dokuwikin/doku.php
[error] PHP Warning: setcookie() expects at most 6 parameters, 7 given in /usr/local/dokuwiki-2014-05-06/inc/auth.php on line 1334, referer: https://server/dokuwikin/doku.php

Looks like the new version of dokuwiki does not support php < 5.2 anymore.

Tue Mar 25 16:08:46.376850 2014] [:error] [pid 2483] [client [omitted]:59470] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 2557874757 bytes) in /usr/share/dokuwiki/inc/phpseclib/Crypt_Base.php on line 602, referer: http://[omitted]/dokuwiki/doku.php?id=start&do=login&sectok=35c889032489133485b10853a6304461

I know this looks like a common PHP config issue at first glance but this is a little different, 2,557,874,757 bytes? ~2.5GB is a bit excessive no? When I try to set memory_limit in php.ini to 3GB the whole web server crashes.

The french translation of "Please contact the admin!" is "Veuillez contacter l'administrateur !" and not "Contactez l'administrateur.".

Note : "Please" = "Veuillez" or "S'il vous plaît".

$lang['btn_subscribe'] = 'S'abonner à la page';
should be replaced by :
$lang['btn_subscribe'] = 'S'abonner à cette page';

It will be more logical because of the others translations :
$lang['btn_edit'] = 'Modifier cette page';
$lang['btn_create'] = 'Créer cette page';
$lang['btn_backlink'] = 'Liens vers cette page';
$lang['accessdenied'] = 'Vous n'êtes pas autorisé à voir cette page.';

Sometime the above test fails at Travis. Rerunning the test usually make it pass just fine. Probably some rare condition (relying on different timestamps but something happening within the same second).

1) cache_use_test::test_use
Failed asserting that false is true.
/home/travis/build/splitbrain/dokuwiki/_test/tests/inc/cache_use.test.php:29

I'm suffering the problem with PHP 5.5 I thought about using Vagrant in dev enviroment (I'm using PHP 5.4 in production).

After installing everything (Ubuntu 12.04 with LAMP) a fresh install of DokuWiki works nice but with my project I've got this error:

Warning: file_get_contents(/home/tascaven/aplications/ubuserver/data/meta/entrada.meta): 
failed to open stream: Operation not permitted in 
/home/tascaven/aplications/ubuserver/public/inc/io.php on line 100
 Call Stack: 0.0280 354724 1. {main}() /home/tascaven/aplications/ubuserver/public/doku.php:0 
1.9068 6908424 2. pageinfo() /home/tascaven/aplications/ubuserver/public/doku.php:51 1.9120 
6911696 3. p_get_metadata() /home/tascaven/aplications/ubuserver/public/inc/common.php:187 
1.9120 6911856 4. p_read_metadata() /home/tascaven/aplications/ubuserver/public/inc/parserutils.php:209 1.9127 6912028 5. 
io_readFile() /home/tascaven/aplications/ubuserver/public/inc/parserutils.php:394
 1.9134 6912144 6. file_get_contents() /home/tascaven/aplications/ubuserver/public/inc/io.php:
100 Warning: fopen(/home/tascaven/aplications/ubuserver/data/meta/entrada.changes): failed 
to open stream: Operation not permitted in /home/tascaven/aplications/ubuserver/public/inc/changelog.php on line 370 
Call Stack: 0.0280 354724 1. {main}() /home/tascaven/aplications/ubuserver/public/doku.php:0 1.9068 6908424 2. 
pageinfo() /home/tascaven/aplications/ubuserver/public/doku.php:51 2.5694 9923832 3. getRevisionInfo()
 /home/tascaven/aplications/ubuserver/public/inc/common.php:196 2.5757 9924488 4.
 fopen() /home/tascaven/aplications/ubuserver/public/inc/changelog.php:370

Any idea?

NOTE: it only happens in Vagrant

I'm tryint to embed dynamic images according to https://www.dokuwiki.org/images#dynamic_images, but when I my URL contains chars such as '{' or '}', the image is not generated. To reproduce the bug try to use links from yuml.me service:

• http://yuml.me/diagram/scruffy/usecase/[Customer]-(Login), [Customer]-(note: Cust can be registered or not{bg:beige})
• http://yuml.me/diagram/scruffy;/usecase/(note: figure 1.2{bg:beige})

(you have to add the &.png? suffix to each link when trying to use them in dokuwiki)

I think this project could majorly benefit from some of the new semantics and elements from HTML5; particularly the <section> element. We can use sections and push the header for each section into the body of the section; see the HTML5 Outline Algorithm.

For example:

<h1 class="sectionedit1" id="level_1_heading">Level 1 Heading</h1>
<div class="level1">
  <p>Level 1 content</p>
</div>
<h2 class="sectionedit2" id="level_2_heading">Level 2 Heading</h2>
<div class="level2">
 <p>Level 2 content</p>
</div>

Would become something like:

<section id="s1.0">
  <h1 class="sectionedit1" id="level_1_heading">Level 1 Heading</h1>
  <section class="level1 levelbody">
    <p>Level 1 content</p>
  </section>
  <section id="s1.1">
    <h2 class="sectionedit2" id="level_2_heading">Level 2 Heading</h2>
    <section class="level2 levelbody">
     <p>Level 2 content</p>
    </section>
  </section>
</section>

The nested nature makes it easier to work with in tools such as CSS or DOM parsers.

We can also use other HTML5 elements such as <nav>.

This would be a substantial HTML refactor and as such as BC considerations. If approved I would be willing to put in a substantial amount of work. I have motivation for doing this because wiki.php.net uses docuwiki and I need to upgrade it anyway.

Even if we don't convert to HTML5 I think we can do some HTML improvements (such as pushing the headers inside the <div> as per the HTML4 Outline Algorithm and applying some lessons from the [Problems Solved by HTML5](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Sections_and_Outlines_of_an_HTML5_document#Problems Solved by HTML5) section.

In dokuwiki\lib\scripts\jquery\jquery.min.js is a call

"e.returnValue=!1"

which is deprecated and issues a warning in chrome

Would like to get a workaround please.

Hello

Do you have plan to provide a specific namespace where logged in users could have their own homepage ?

Ref:
https://www.dokuwiki.org/tips:homepages
https://www.dokuwiki.org/plugin:userhomepage

If I want to write something like
form.innerHTML
as text in a page, it gives me a 403 error.

If I just write
.innerHTML into a page
as text, it gives me an error.

I can write
. innerHTML
(with a space in between)
and that works.

I'd like to be able to write .innerHTML in pages when I'm giving code examples. Placing it in a code block doesn't help.

I did some changes in layout by using lib/tpl/vector/user/screen.css in Binky. This worked well. Today I upgraded to Ponder Stibbons. After that the configurations in lib/tpl/vector/user/screen.css are ignored. I checked, that the file is in place and unchanged. Any idea, whats wrong?

My screen.css:

/* en: Place for user defined CSS rules (screen media) - this file can safely be
   preserved when updating. See README for details.

   de: Ort für benutzerdefinierte CSS-Regeln (screen media) - Diese Datei kann
   beim Durchführen von Updates ohne Risiko beibehalten werden. Konsultieren Sie
   die README für Detailinformationen. */



/* Sidebar breiter machen (15em statt 10em) */
div#content,
#head-base,
div#footer,
div#panel,
#p-logo,
#p-logo a,
#left-navigation {
    margin-left: 15em !important;
}

DokuWiki already contains support for the non-standard URI scheme callto: (unfortunately because of its special meaning : has to be replaced by >). Contrary to the URI scheme above tel: is standardized in RFC3966. There are also some examples of the tel: URI.

It would be ideal if the tel: URI had an icon in the same design as the http: and mailto: URIs. I.e. a monochrome grey icon though the icon which is used for callto: is OK.

when you get the page versions using xmlrpc, then you can increment the offset-parameter to infinity, dokuwiki will always return items.
so this is not possible:

i=0
versions = getPageVersions(pagename, i)
while len(versions):
  i+=1
  versions = getPageVersions(pagename, i*len(versions))

... because it never stops. (And there is to my testing no other reliable indicator available for "all versions fetched").

To facilitate use of a common handler, the events:

• INDEXER_PAGE_ADD
• FULLTEXT_SNIPPET_CREATE
• FULLTEXT_PHRASE_MATCH
  should use the same parameters, in a compatible way possible using '&' aliasing to keep current parameter names.

I tried several different downloads:

• the download button at the top of the download page - http://download.dokuwiki.org/
• the direct link to the stable version in the "Version" section of the download page
• the customized download

In all cases the lib/plugins/ directory was missing, although it is present in the sources on GitHub under the tag "stable_release_2014-05-05".

Hi community,

I've got a Download issue with IE8, when trying to download a file I get a "cannot download fetch.php from " error.
I already found a fix with cache control / pragma headers but that didn't work for me.
Is there an easy fix for this Browser version?

after upgrading my test-dokuwiki to "Ponder Stibbons" there's a problem with "last modified by".
There's no more date and time. ;( it shows now: Last modified: d.m.Y H:i by django

For localized texts you can copy a <filename>.txt to respectivily:
<dokuwiki>/conf/lang/<language>/<filename>.txt
<dokuwiki>/conf/plugin_lang/<pluginname>/<language>/<filename>.txt
<dokuwiki>/conf/template_lang/<pluginname>/<language>/<filename>.txt

This is not yet possible for the lang.php.

Proposal:
extend the localisations cascading with:
<dokuwiki>/conf/lang/<language>/lang.php
<dokuwiki>/conf/plugin_lang/<pluginname>/<language>/lang.php
<dokuwiki>/conf/template_lang/<pluginname>/<language>/lang.php

(Also, add clear examples that people should only override the strings they like to change...
Disadvantage is that people can copy their whole lang.php, and keep the old string overriding updated strings.)

DokuWiki seems not be robust against the (I confess: very rarely occuring) case of running out of disc space. When any free space is used up, and when you go to edit pages, the originally populated page is shown as totally empty. when you then continue, the empty page is saved. Fortunately I can pull back the original content, if I go to "last changes" view and pick the previous state of the document. But, it occured that many randomly pages where empty even after I "cured" the missing disk space, and these have been pages, which I did not change recently. This means, I had to go through all pages checking if content was lost. Saving one minimal change at a previous version was enough to restore each document.
I see there a risk of loss of markup/page content data. (It is really the only data loss thread I experienced in many weeks working happily with dokuwiki.)

(Debian 7 Wheezy running DokuWiki Version "Git 2014-04-26")

For compatibility with PHP configurations that don't support https we are currently requesting the extension repository information via http. However unfortunately this means that all screenshot URLs (that contain the absolute URL) contain "http" as protocol even if the DokuWiki installation itself is using https.

There are various possible fixes:

• Change the extension manager to adjust the URLs
• Change the repository to use HTTPs URLs regardless of the request protocol or to not to include any protocol at all
• Request the repository via HTTPs either if the PHP installation supports it (can we determine that?) or if DokuWiki itself is used via HTTPs

file icon is only 16x16 and media icons are 32x32

public function getUserData($user, $inbind = false)

This makes it problematic to change the public interface later for other plugins which are based off the same code (e.g. authldaplocal).

I think its better to create an internal method which uses extra parameters, e.g.

public function getUserData($user) {
  return this->_getUserData($user);
}
protected function _getUserData($user, $inbind = false) {
...
}

This issue relates to FS#2086 which requests extending getUserData() to indicate whether group information is required. Adding an additional parameter to support the new behaviour would conflict with authldap and derivatives.

just got this via email:

Recently switching our servers to PHP 5.5 we noticed that a login to the Dokuwiki instance does not work anymore, the session is lost after the redirect.

We debugged your the code and this is what needs to be changed to make Dokuwiki work on PHP 5.5:

When starting a session always check if the session is already active, otherwise PHP 5.5 will renew the session and that leads to loosing the previously opened session. That's why a login is lost:

Use this code to start a session:

            /*--PHP 5.5--*/
            if (version_compare(PHP_VERSION, '5.4.0') >= 0) {
                if (session_status()==PHP_SESSION_NONE) { session_start(); }
            } else {
                if(session_id()=='') { session_start(); }
            }

I know it's not directly related to dokuwiki, but I can't report on the bugtracker since I can't register...

Strict standards: Non-static method Validate::email() should not be called statically in /var/www/bugs/htdocs/includes/class.flyspray.php on line 943 Call Stack: 0.0000 233288 1. {main}() /var/www/bugs/htdocs/index.php:0 0.0045 1151136 2. require_once('/var/www/bugs/htdocs/includes/modify.inc.php') /var/www/bugs/htdocs/index.php:144 0.0053 1276248 3. Flyspray::check_email(string(21)) /var/www/bugs/htdocs/includes/modify.inc.php:276 Dump $_SERVER $_SERVER['REQUEST_URI'] = '/index.php?do=register'