Bug #15861

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

Added by Kasper Skaarhoj over 14 years ago. Updated about 14 years ago.

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

0%

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)

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


Related issues

Related to TYPO3 Core - Bug #15579: bug on storing mm_relations Closed 2006-03-12
Related to TYPO3 Core - Bug #16518: MM relations should be editable from both sides of the relation Closed 2006-09-01

History

#1 Updated by Michael Stucki over 14 years ago

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

#2 Updated by Michael Stucki over 14 years ago

Fixed by reverting the whole patch.

Also available in: Atom PDF