typo3-caretaker / caretaker_instance Goto Github PK

Hi

in the composer.json you have classmap: "classes/" which is lowercase but the folder is uppercased "Classes", on a case sensitive filesystem this leads to class not found exceptions.

Greetings
Daniel

Localisations are stored in locallang.xml.

They should be migrated to XLIFF xx.locallang.xlf.

Hi,

there is a conflict with Ext. Booking (https://extensions.typo3.org/extension/booking/). If both extensions (caretaker_instance 3.0.3 and booking 1.4.5) are installed, calling index.php?eID=tx_caretakerinstance&rst=1 doesn't work any more. The eID parameter gets ignored and the normal website is shown. The reason for this is booking/Configuration/RequestMiddlewares.php:
return [
'frontend' => [
'typo3/cms-frontend/eid' => [
'disabled' => true,
],

Since this isn't a fault of caretaker_instance, you can close this issue right away.
I just want to let people know in case they run into the same problem.
I created a issue for booking: joachimruhs/booking#2

Cheers, Tobias

As of now it does not work. I get:

Fatal error: Call to undefined method
TYPO3\CMS\Frontend\Utility\EidUtility::connectDB()
in typo3conf/ext/caretaker_instance/eid/eid.tx_caretakerinstance.php on line 51
Typo3 7.0.2

Is there any planing to have - at least the client - run with later Typo3 versions?

Hi,
we are don't able to monitor a caretaker_instance on a TYPO3 V10 with the version 3.0.0

Permant errors on the caretaker server (TYPO3 V8) with server version 1.02:
Command execution failed: Request Session Token failed:

• HTTP-URL: https://www.domain.tld/index.php?eID=tx_caretakerinstance&rst=1
• HTTP-Status: 500
• Screenshot of an TYPO3 Oops an error occured

The keys are correctly generated and in LocalConfiguration.php. Also the public key of the server is correct.

On the local instance in this installation (client) we get this debug information:

For information: we're using composer mode for the instance and server.

Greets
Huaba

I just updated the caretaker_instance to the new version 0.5. Since that the sheduler does not work correctly. Errormessages are thrown:

TYPO3 Exception: caretaker testservice tx_caretakerinstance_Extension not found

I did rollback to version 0.4.1 and evryrthing works fine.

Line 56 is list($path) = glob($path);.

Here list() assigns the index 0 of glob($path). glob() returns an array containing the matched files/directories, an empty array if no file matched or false on error. The last two cases will fail to be assigned because there is no entry in the array - or it is no array (false).

This use-case might be caused by not setting any paths to be checked.
Looking to tx_caretakerinstance_CheckPathTestService.php#L63: $paths = explode(chr(10), $paths);
$path will be a non-empty array even if the separator is not found ("If separator contains a value that is not contained in string and a negative limit is used, then an empty array will be returned, otherwise an array containing string will be returned. "). Exactly this will be, if $pathsis an empty string - there's no chr(10) in it, and explode() return array(0=>'').
In line 64 this empty string will be processed and cause the above warning due to an invalid/empty path.

class.tx_caretakerinstance_Operation_GetRecords.php still tries to load the TCA via $GLOBALS['TSFE']->includeTCA(); which does not exist anymore.
Please remove \tx_caretakerinstance_Operation_GetRecords::includeTCA completely and replace /class.tx_caretakerinstance_Operation_GetRecords.php:129
$this->includeTCA(); with \TYPO3\CMS\Frontend\Utility\EidUtility::initTCA(); like it was done in Web/typo3conf/ext/caretaker_instance/classes/class.tx_caretakerinstance_Operation_GetRecord.php:75

Do you have plans for a version that is compatibility with TYPO3 V8.

The check for blacklisted passwords is deprecated and not compatible with current password encryptions.

The check is to be removed.

With v0.5.0 of the caretaker instance extension the test case "Check be-password blacklist" is failing with a 500 Internal Server Error on two of our TYPO3 client installations (both on 4.5 LTS). Once we downgraded to v0.4.1 everything seemed to work fine.

Add a check for frontend users:

• Check username
• Check email

(See Backend user)

My idea is to make a blacklist possible for frontend users. Don't hesitate to contribute your ideas.

See https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Database/Migration/Index.html

Hello there! Thank you for the compatibility update for TYPO3 9.5, but sadly there is a bug in version 2.0.0:

You can't store the created keys by class.ext_update.php to LocalConfiguration. I wrote a hot fix patch, but maybe there is a better way to do it.

class.ext_update.patch.zip

I cannot install caretaker_instance on typo3 because of the error message : The package "caretaker_instance" depends on "typo3/cms" which is not present in the system.

Is it because of my System? what could i do?

Hello,

i just noticed after controlling the installed version of the caretaker extension in TYPO3 CMS, that the tag is not consistent with the exteniosn version:

• /ext_emconf.php -> 'version' => '0.8.0',
• tag: 0.8.1 ref abaaf93ef344c9e4a5cd175a0a3d77730b839884

Greetings

Due to not anymore supported class.ext_update.php there is no possibility to create the keys on new installs.

I'm not sure, if the Upgrade Wizard is the correct replacement.

The most practical way would be to generate the keys on installation of the extension if there is not already a pair of keys set.

Can we soon expect a packagist/TER version for 8.x? Thanks so much.

Due to the latest ter release in 01.08.2020 outdated extensions are getting review_state -2.
We stumbled upon this since we monitor a few older 7.6 instances.
Even the latest caretaker extension itself is now shown as insecure.
Those extensions are now flagged as insecure due to this changes:

https://git-t3o.typo3.org/t3o/ter/-/commit/9e153c5033c165b8c5f3a128cba4f98b510bc587#bed6f0022ede9bd16f1f4e64c908e4aae1ba7640
https://gitlab.typo3.org/t3o/ter/-/blob/develop/extensions/ter_fe2/Classes/Domain/Model/Version.php#L139

I would propose to ignore the outdated version and only trigger if insecure is flagged.
T3O confirmed this behaviour as outdated is only a notice, but no indicator for insecure. If an outdated version gets reported and shows security issues, its flagged again as -1.

Can we think about this again?

e00f12a#diff-85035a0cade545b687554eb75b5a191cR112

I created a test to check the configuration of an extension. The field I'm checking against contains numeric values. I want to make sure that the number in that field is greater than 4 so i would expect to put in the following test configuration:

EXT|extConf|myext|numeric_value_field>=5 or
EXT|extConf|myext|numeric_value_field>4

The first line reads to me as follows (like the label of the test configuration field suggests): The actual value of EXT|extConf|myext|numeric_value_field is greater than or equals to 5. But that's not what is done in the code. The check is reversed leading to: 5 is greater than or equal to the actual value of EXT|extConf|myext|numeric_value_field which allows only values from 0-5 and not like expected greater than or equal to 5.

So the only working solution would be to reverse the condition of the first line.

EXT|extConf|myext|numeric_value_field<=5

I thought reversing the condition of the second line would do the same trick but it didn't.

The problem only applies to the lower and greater than comparisons as it matters on which side of the comparison a value is. For equal/not equal and regex comparisons there isn't a similar problem.

Do I miss something, is this intended behaviour or a bug?

The FindBlacklistedBePasswordsTest tries to "select" be_users with a given password, but expects the password to be stored as MD5 in the instance database. So, if EXT:saltedpasswords is installed on the instance this wont work.

In deprecation log of TYPO3 7 TLS:

 Extension "caretaker_instance" defines a dependency on ext:cms, which has been removed. Please remove the dependency.

https://github.com/TYPO3-Caretaker/caretaker_instance/blob/master/ext_emconf.php#L28

Hi

There are two folders with the same name in the Unit Test path. Please merge these folders to one.

https://github.com/TYPO3-Caretaker/caretaker_instance/tree/master/Tests/Unit

Why? Look below

svn st | grep caret
? typo3conf/ext/caretaker_instance/Tests/Unit/Fixtures/Operation_CheckPathExists.txt
? typo3conf/ext/caretaker_instance/Tests/Unit/Fixtures/Operation_GetFilesystemChecksum.txt
! typo3conf/ext/caretaker_instance/Tests/Unit/fixtures
? typo3conf/ext/caretaker_instance/Tests/Unit/fixtures/DummyOperation.php

• update class structure / naming
• use namespaces
• for backwards compatibility see (https://github.com/TYPO3/class-alias-loader and https://github.com/FriendsOfTYPO3/compatibility6/tree/master/Migrations/Code)

The test causes an import error:

PHP Fatal error: Class 'TYPO3\CMS\Frontend\Utility\EidUtility' not found in /PATH/TO/TYPO3CONF/ext/caretaker_instance/classes class.tx_caretakerinstance_Operation_GetRecord.php on line 77

I'm using caretaker 0.5.0, caretaker_instance 0.5.0 and TYPO3 4.5.35

Thank you
Andreas

I have TYPO3 4.5.35 with caretaker and caretaker_instance from git master branch. When scheduler runs I get following error message:
PHP Fatal error: Call to undefined method tx_caretakerinstance_FindExtensionUpdatesTestService::versionToInt() in /path/to/typo3conf/ext/caretaker_instance/services/class.tx_caretakerinstance_FindExtensionUpdatesTestService.php on line 278