Project

General

Profile

Actions

Bug #31869

closed

Wrong path to t3lib_utility_Client class in hooks

Added by Tomasz Krawczyk about 13 years ago. Updated about 11 years ago.

Status:
Rejected
Priority:
Won't have this time
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2011-11-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

There is wrong path to t3lib_utility_Client class in its hooks. There is no 'div' subdirectory in t3lib directory from TYPO3 v. 4.5.3 to 4.5.7. The t3lib_utility_Client class is located in t3lib/utility/ directory.

Putting the 't3lib/div/class.t3lib_utility_client.php' path to an (ext_)localconf.php should work because it is a $TYPO3_CONF_VARS['SC_OPTIONS'] array key but it is confusing.

Actions #1

Updated by Jigal van Hemert about 13 years ago

  • Category set to Backend API
  • Status changed from New to Needs Feedback

I don't think we should change this path, which is like this since August 2009. Changing it directly would cause all code that uses this hook to stop working.
Modifying it and deprecating the old path is hardly worth the trouble IMO.

Actions #2

Updated by Markus Klein about 13 years ago

Note: The same (wrong) path is also present in current master (4.7).

Actions #3

Updated by Tomasz Krawczyk about 13 years ago

If it is because of backward compatibility than ok.

Both hooks in this file are commented. I think it would be good to put there a short comment in order to avoid further developers questions.

BTW. Can you tell since which version such path exists in the core?

Actions #4

Updated by Alexander Opitz about 11 years ago

  • Status changed from Needs Feedback to New
  • Is Regression set to No
Actions #5

Updated by Ernesto Baschny about 11 years ago

  • Status changed from New to Rejected
  • Priority changed from Should have to Won't have this time

Meanwhile (since 6.0) the files are at a totally different location anyway, so the old hooks all refer to files that do not exist anymore.

If you need to find one hook having it's name (i.e. if it is referred to in an extension), you can simply "grep" the current source code to find where it hooks into. If you on the other hand have the hook in the Core you can simply copy&paste the hooks array keys to your extension.

So currently I see no other way of dealing with it - despite that it "looks ugly".

Actions

Also available in: Atom PDF