Bug #15861

Recent "fixes" in t3lib_loaddbgroup introduces potentially hard found bugs in 3rd party applications

Added by Kasper Skaarhoj over 15 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
-
Target version:
-
Start date:
2006-03-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.0
PHP Version:
4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The internal variable ->itemArray in t3lib_loaddbgroup doesn't use numerical keys that indicates order of elements. The key is now a string, being a combination of table and uid.

This introduces the following problems:
- Applications like sys_refindex (core), TemplaVoila (external!) are using the key as sorting key (0,1,2...) etc. We can't know how many other applications are relying on this (for years!)
- Using table_uid will disallow duplicate entries in the array - an obvious feature of TYPO3!!!
- The implementation is probably buggy; in function readList() values are put into $this->itemArray[$itemKey] and $this->itemArray[$key] suggesting an incomplete implementation.

I would like this reverted immediately or otherwise be presented for compelling evidence why this is necessary!

I would also like to know how Rene will defend that a (de facto) "public API" like ->itemArray should change so radically.

(issue imported from #M2932)


Files

revert_mm_complete.diff (19.4 KB) revert_mm_complete.diff Administrator Admin, 2006-03-21 20:13

Related issues

Related to TYPO3 Core - Bug #15579: bug on storing mm_relationsClosedRené Fritz2006-03-12

Actions
Related to TYPO3 Core - Bug #16518: MM relations should be editable from both sides of the relationClosedSebastian Kurfuerst2006-09-01

Actions
#1

Updated by Michael Stucki over 15 years ago

Attached is a patch that reverts the whole MM stuff introduced by René.

#2

Updated by Michael Stucki over 15 years ago

Fixed by reverting the whole patch.

Also available in: Atom PDF