[TYPO3-dev] Pre-RFC: Enable Sysfolder for usage with CONTENT
Sebastian Gebhard
sebastian.gebhard at gmail.com
Mon Nov 30 10:41:38 CET 2009
Hi *,
with CONTENT you can catch data from a lot of different tables. You can use all tables that are
named like tx_*, tt_*, ttx_*, fe_*, user_*, static_* and pages - in short almost everything that's
Frontend related.
The fact that you can get records from pages is not fully true. There's a restriction that bugged me
recently: You can only get "visible" pages, which means delted = 0 AND hidden = 0 (fully ok so far)
AND doktype<200.
To explain the 200 value: The doktypes above 200 are Sysfolders and Recyclers, which are generally
not visible to the frontend.
But there are cases where reading Sysfolders with CONTENT can be important. Think of categories,
which commonly can either be provided by category records (like tt_news_cat) or by sysfolders. But
when you use Sysfolders you can not create something like a category menu with CONTENT.
My proposal is to introduce a new property *CONTENT.select.checkDoktype* which is true by default
and restricts Doktypes to < 200. But you can disable it to get all pages.
I hope most of you are with me so far and agree that this is useful.
When I tried an implementation this appeared tougher than i thought.
The "enable fields" for the pages in CONTENT are set up in class.tslib_content.php in line 7782 (trunk):
if ($table=='pages') {
$query.=' '.$GLOBALS['TSFE']->sys_page->where_hid_del.
$GLOBALS['TSFE']->sys_page->where_groupAccess;
}
$GLOBALS['TSFE']->sys_page->where_hid_del includes not only "hidden = 0 and deleted = 0" what its
name suggests it also contains restrictions for starttime, endtime, versioning and doktype<200.
The doktype thing is hardcoded in class.tslib_fe.php:setSysPageWhereClause() in line 1361 (trunk):
$this->sys_page->where_hid_del.=' AND pages.doktype<200';
This is called in the wide initialization process of tslib_fe. So when the FE is initialized
"doktype<200" is already fixed.
So the only solution I can come up with looks like this:
if ($table=='pages') {
$query.=' '.$GLOBALS['TSFE']->sys_page->where_hid_del.
$GLOBALS['TSFE']->sys_page->where_groupAccess;
// New property CONTENT.select.checkDoktype
if(isset($conf['checkDoktype']) && $conf['checkDoktype'] == 0) {
$query = str_replace(' AND pages.doktype<200', '', $query);
}
}
The restriction is just str_replace'd, which seems rather dirty to me.
Another possbile way would be to introduce a new function enableFields() to t3lib_pageSelect but
keep where_hid_del there for compatibility, because it's used throughout the core. The new function
could accept some parameters, maybe it could look like this:
string enableFields($restrictHidden = TRUE, $restrictDeleted = TRUE, $restrictStartEnd = TRUE,
$restrictDoktype = TRUE)
Over time all occurencies of the unflexbile where_hid_del should be replaced.
What do you think?
Is my str_replace solution too dirty for the core?
Does t3lib_pageSelect:enableFields make sense to you?
Other proposals to get the enable fields for pages more flexible?
Kind regards,
Sebastian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: checkDoktype.diff
URL: <http://lists.typo3.org/pipermail/typo3-dev/attachments/20091130/af5a2799/attachment.asc>
More information about the TYPO3-dev
mailing list