History log of /dokuwiki/inc/Search/Indexer.php (Results 1 – 20 of 20)
Revision Date Author Comments
# 8407f251 02-Dec-2024 splitbrain <86426+splitbrain@users.noreply.github.com>

�� Rector and PHPCS fixes


# 0f7af8fc 25-Nov-2024 Andreas Gohr <andi@splitbrain.org>

replace E_USER_ERROR triggers with RuntimeExceptions

The use of trigger_error with a E_USER_ERROR is deprecated in PHP 8.4


# 6c16a3a9 14-Sep-2023 fiwswe <fiwswe@fwml.de>

Use str_starts_with/str_ends_with


# 90fb952c 31-Aug-2023 Andreas Gohr <andi@splitbrain.org>

code style: operator spacing


# 7d34963b 31-Aug-2023 Andreas Gohr <andi@splitbrain.org>

coding style: control flow line breaks


# 177d6836 31-Aug-2023 Andreas Gohr <andi@splitbrain.org>

coding style: control flow whitespaces


# a19c9aa0 30-Aug-2023 Gerrit Uitslag <klapinklapin@gmail.com>

recover comments in list


# dccd6b2b 30-Aug-2023 Andreas Gohr <andi@splitbrain.org>

coding style: function call spacing


# b2c8ab47 30-Aug-2023 Andreas Gohr <andi@splitbrain.org>

coding style: loop declaration spacing


# d868eb89 30-Aug-2023 Andreas Gohr <andi@splitbrain.org>

codestyle adjustments: function declaration braces/spaces


# 8c7c53b0 30-Aug-2023 Andreas Gohr <andi@splitbrain.org>

codestyle adjustments: class declaration braces


# c1482d1c 30-Aug-2023 Andreas Gohr <andi@splitbrain.org>

codestyle adjustments: function argument spacing


# 24870174 29-Aug-2023 Andreas Gohr <andi@splitbrain.org>

Apply rector fixes to the rest of inc


# ac1d8211 19-Mar-2023 Andreas Gohr <andi@splitbrain.org>

fix some php 8.2 deprecation warnings


# 173de31c 24-Jan-2023 Moritz Raguschat <moritz.raguschat@web.de>

Avoid some unnecessary index file writes.

word_idx modified should be reset to false for each word index file, or all unchanged word index files after the first changed one will be resaved unnecessa

Avoid some unnecessary index file writes.

word_idx modified should be reset to false for each word index file, or all unchanged word index files after the first changed one will be resaved unnecessarily.

show more ...


# bd539124 14-Aug-2021 Andreas Gohr <andi@splitbrain.org>

: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 ...


# 7c392639 27-Jan-2021 Damien Regad <dregad@mantisbt.org>

Fix Undefined array key in Search/Indexer.php


# 23420346 26-Jan-2021 Damien Regad <dregad@mantisbt.org>

Fix Undefined array key "fperm" warning

Also removed a few, now unnecessary `!empty` checks

Fixes #3382


# 3aa75874 18-Feb-2020 movatica <c0d3@movatica.com>

Fixed inconsistent handling of falsy values on fperm setting

The $conf['fperm'] value was checked in multiple files using different methods.
This can cause permission trouble with restricted environ

Fixed inconsistent handling of falsy values on fperm setting

The $conf['fperm'] value was checked in multiple files using different methods.
This can cause permission trouble with restricted environments, i.e. when chmod is forbidden and file permissions are non-default.
Now, all checks use implicit cast to boolean which leads to consistent behaviour.

Also, a misleading variable was renamed in context to better understand one of the checks.

show more ...


# 6225b270 28-Dec-2019 Michael Große <mic.grosse@googlemail.com>

Extract dokuwiki\Search\Indexer class

Not sure why Doku_Indexer caused phpcs to complain about the class name
not being in PascalCase, but Doku_Handler didn't. ��

The namespace and new class name w

Extract dokuwiki\Search\Indexer class

Not sure why Doku_Indexer caused phpcs to complain about the class name
not being in PascalCase, but Doku_Handler didn't. ��

The namespace and new class name was selected to be compatible with the
upcoming changes in #2943. This should hpopefully reduce the overall
hassle of touching the same code base.

show more ...