Changed IndexAccessor names based on access method not content

Add support to access multiple rows at once

When saving word indexs (w*.idx) often multiple words of the same length
will need to be accessed. This implements a new method that allows that
in an eff

Add support to access multiple rows at once

When saving word indexs (w*.idx) often multiple words of the same length
will need to be accessed. This implements a new method that allows that
in an efficient way.

Note: this removes the INDEX_MARK_DELETED mechanism to mark deleted
entries. Entries are now deleted using empty lines again. This makes the
batch handling much simpler. If a good reason exists that we should keep
it, it can be readded.

show more ...

rearranging the Index class structure

This is a first step at stuff at restructuring the indexing classes a
bit more.

Some background:

We have basically two different kind of index files:

a) RowI

rearranging the Index class structure

This is a first step at stuff at restructuring the indexing classes a
bit more.

Some background:

We have basically two different kind of index files:

a) RowIndex (like page.idx)

Each line in the index contains a single value. The line number is used
as primary ID. These files can be very large. Thus an index like that
should never be read into memory completely if it can be avoided.

b) TupleIndex (like i12.idx)

Each line contains a list of tuples. The files tend to be smaller so
loading them completely for search and replace is easier.

Since the the access is so completely different, I tried to model that
in the two different classes, basically moving the methods from
\dokuwiki\Search\AbstractIndex to the new classes.

While doing so, I tried to make the doc blocks, variable names and
interface easier to understand. I also added tests for each of the
methods.

The old code has not been touched yet. So these classes do not do
anything outside of tests currently.

show more ...

Update common_saveWikiText.test.php

allow 2nd to last revision check for normal save

update unittest checkChangeLogAfterNormalSave

add routine for "save on top of external edit" assertions

saveWikiText() unittest 5

5.1 create a page
5.2 external edit
5.3 edit and save
5.4 delete
5.5 create a page, second time
5.6 externally delete
5.7 create a page, third time

saveWikiText() unittest 3.3

second to last revision check after repeated external edit

saveWikiText() unittest 4

4.1 externally create a page
4.2 edit and save
4.3 externally edit (file older than last rev)

group assertions for saveWikiText()

removed wrong test

See
https://github.com/splitbrain/dokuwiki/pull/3272#issuecomment-966367900
for reasoning

fix fallback implementation for resolve_pageid()

When an empty link was given, the old implementation fell back to $ID,
this was handled incorrectly in the deprecated method.

simplify relative resolver and add tests

make resolveStartPage easier to understand

This dosn't really change the behaviour but makes the code easier to
grasp. A simple unit test has been added.

Update common_saveWikiText.test.php

getRevisions() may return empty array when changelog file does not yet exist.

rewrite unit test of saveWikiText

fix typo

typo

UnitTest of pageinfo(), saveWikiText()

ChangeLog creates early .change file, p_get_metadata() will get full "meta_last_change" entry. The current key in the revinfo need to be excluded prior to p_s

UnitTest of pageinfo(), saveWikiText()

ChangeLog creates early .change file, p_get_metadata() will get full "meta_last_change" entry. The current key in the revinfo need to be excluded prior to p_set_metadata() call.

show more ...

UnitTest, ApiCore::pageInfo()

author is available from changelog::getRevisionInfo()

UnitTest around changelog, set correct time of page source

ChangeLog constructor will check the date of current page/media file to detect external edits via getCurrentRevisionInfo()

Fix PHPUnit fatal errors compatibility with void.

Method names with leading double underscore are reserved by PHP.

move IXR XML RPC to composer dependency #1970

This is a monky patched version of kissyfrot/php-ixr until my PR has
been accepted upstream.

Plugins using the XML RPC client may need adjustments.

:fire: fix the calculation of file permissons

Our config allows to set the values for `dmode` and `fmode` to allow
users to explicitly define which permissions directories and files
should have.

To

:fire: fix the calculation of file permissons

Our config allows to set the values for `dmode` and `fmode` to allow
users to explicitly define which permissions directories and files
should have.

To avoid unnessary chmod operations, we check the current umask to
compare what permissions files and directories would get witout our
intervention. If the result is already what the user wants, no chmods
will happen later on. Otherwise we set new configs called `dperm` and
`fperm` which will be used in chmod ops. This is done in
`init_creationmodes()`

When we created new directories, we used to pass the original `dmode`
config to `mkdir()`. The system will then apply the umask to that
`dmode`.

This means the resulting directory will *always* have different
permissions than `dmode`, *always* requiring a chmod operation.
That's silly.

**Breaking Change:** This patch removes the passing of `dmode` as
second parameter to all `mkdir` calls, making it default to `0700`
which is also what we test against in `init_creationmodes()`.

Plugins not relying on our `io_*` functions and do create their own
directories and which currenlty pass `dmode` to it need to be
adjusted to remove that second parameter.

Users may want to reapply the proper file permissions to their data
folder.

**Revert:** In 9fdcc8fcd87114ca59a1764a84d213a53c655c8c @movatica
introduced a change to `init_creationmodes()` that compared the umask
against `fmode` instead of `0666`. I merged it because it looked logical
when compared to the code for directories which compared against `dmode`
as described above. However we do not pass `fmode` to any file creation
methods (that's not possible).

The result is that all changes made in the `fmode` setting resulted
in the wrong permissions for newly created files as first reported in
https://forum.dokuwiki.org/d/19463-setting-fmode-not-working-as-intended

I'm unsure about the orginal motivation behind @movatica's change. The
"fix" however, is wrong.

**Tests:** This patch introduces an integration test that will check the
actual results of directory and file creations under various umask,
`dmode` and `fmode` settings.

show more ...

Add support for SHA256 encrypted passwords

Enable detection of SHA256 hashes (prefixed with $5$) and allow to
use this hashing schemes in passwords.