CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.6 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Feature #5397

Enable custom screens for tag input

Added by Francois Suter over 3 years ago. Updated over 2 years ago.

Status:Needs Feedback Start date:2009-11-17
Priority:Could have Due date:
Assignee:Francois Suter % Done:

100%

Category:-
Target version:-
Votes: 0

Description

Tagging in the BE is achieved via a form created using a dynamically added configuration tx_tagpack_tceforms_addtags::getMainFields_preProcess().

In some situations, it might be desirable to use a different input form. Case in point: a client of mine has a limited amout of tags and would like to see them all with checkboxes (furthermore classified by category).

In a first step I'm wondering what the best way would be to have a flexible way of overriding the default TCA added in tx_tagpack_tceforms_addtags::getMainFields_preProcess(). A hook in that method to post-process the TCA? A predefined place to store a TCA configuration that would be used if defined, instead of the default setup?

patch5397.diff (4.6 kB) Francois Suter, 2009-11-24 15:17

tagpack_altselector.png (22.5 kB) Francois Suter, 2009-12-08 11:56

patch5397-v2.diff (4.6 kB) Francois Suter, 2009-12-08 15:59

Associated revisions

Revision 5545
Added by Franz Holzinger almost 6 years ago

fix bug 5256: replace also the , in str_replace in order not avoid replacement of other fields with the same name but from other extensions.
fix bug 5397: images could not be uploaded and have not been shown

History

Updated by Francois Suter over 3 years ago

Having had no answer, I'm coming up with a proposal. The attached patch enables the following syntax (for example to override the tag selector for the "pages" table):

$TCA['tx_tagpack_tags']['tagpack_options']['alternateTCA']['pages'] = array(...);

The array contains a TCA-column configuration. Note that the syntax itself is not standard TCA, but that causes no disturbance. I thought about using TYPO3_CONF_VARS first, but this causes problems with the loading order of the temp_CACHED_* files.

The attached patch changes class tx_tagpack_tceforms_addtags to make it aware of such configurations. It will first check for $TCA['tx_tagpack_tags']['tagpack_options']['alternateTCA']['*tablename*'] to override the settings for a specific table. It then checks for $TCA['tx_tagpack_tags']['tagpack_options']['alternateTCA']['*default*'] that will override settings for all tables. If none of these are found, it moves on to the normal field setup (group-type with wizard).

What do you think? I find it really useful to be able to have a different rendering for the tags selector in special cases (and indeed I have a client request for that).

Updated by Jo Hasenau over 3 years ago

While I really like the option of having different TCA for different records, I am afraid that the "not standard TCA syntax" will be suboptimal.
Do you think this can be solved by an "official TCA" approach instead?

Updated by Francois Suter over 3 years ago

While I really like the option of having different TCA for different records, I am afraid that the "not standard TCA syntax" will be suboptimal. Do you think this can be solved by an "official TCA" approach instead?

The problem is that the TCA for the dynamic tags field is inside class.tx_tagpack_tceforms_addtags.php, so it cannot be overridden by another extension's ext_tables.php. I understand that it's weird to use a non-standard TCA syntax (although I use an extended TCA syntax in an extension of mine and it feels quite logical, but it's a different circumstance).

TYPO3_CONF_VARS cannot be used, as mentioned in my original report.

One possibility I can see is to use T3VAR instead. I haven't tried but the DAM uses it to have predefined MM fields configuration, so it should be ok using for tagpack too. What do you think?

Example taken from EXT:dam/tca_media_field.php:

$GLOBALS['T3_VAR']['ext']['dam']['TCA']['media_config'] = array (
    'form_type' => 'user',
    'userFunc' => 'EXT:dam/lib/class.tx_dam_tcefunc.php:&tx_dam_tceFunc->getSingleField_typeMedia',

    'userProcessClass' => 'EXT:mmforeign/class.tx_mmforeign_tce.php:tx_mmforeign_tce',
    'type' => 'group',
    'internal_type' => 'db',
    'allowed' => 'tx_dam',
    'prepend_tname' => 1,
    'MM' => 'tx_dam_mm_ref',
    'MM_foreign_select' => 1, // obsolete in 4.1
    'MM_opposite_field' => 'file_usage',
    'MM_match_fields' => array('ident' => 'relation_field_or_other_ident'), #### has to be changed in table

    'allowed_types' => '',
    'disallowed_types' => 'php,php3',

    'max_size' => 10000,
    'show_thumbs' => 1,
    'size' => 5,
    'maxitems' => 200,
    'minitems' => 0,
    'autoSizeMax' => 30,
);

Updated by Jo Hasenau over 3 years ago

  • Status changed from New to Accepted

Updated by Francois Suter over 3 years ago

I saw that you changed the status to "accepted". Does that mean that you find the solution with T3_VAR acceptable? Are you taking over or do you expect a new patch from me (which is fine, I'm working on that again today)? I'm not sure how we proceed from here.

Updated by Francois Suter over 3 years ago

For information I finished a first working version of my extension that would introduce a custom screen. You can find it at:

https://svn.typo3.org/TYPO3v4/Extensions/tagpack_altselector/trunk

if you want to test this issue. Attached a screenshot to give you an impression.

Updated by Francois Suter over 3 years ago

  • Assignee set to Francois Suter

OK, moving ahead with the T3_VAR proposal.

Updated by Francois Suter over 3 years ago

Here's an updated version of my patch, using T3_VAR instead of the originally proposed pseudo-TCA.

Extension tagpack_altselector has been updated accordingly. For proper testing note that:

- the alternate tag selector is defined only for the pages table
- it expects tags to have categories. So if you have none, you'll probably end up with a very long list of checkboxes.

Updated by Jo Hasenau over 3 years ago

Since we are working on trunk, I guess we don't have to be as restrictive as the core people here.
So if you believe in your patch and you know it is working, feel free to commit it, so we can test it and give you some feedback.

After all we got versioning to be able to revert stuff ;-)

Updated by Francois Suter over 3 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Thanks for the green light!

Committed to trunk in revision 27469.

Here's a short documentation for the record:

To override the default TCA configuration for the tag selection field, you can store an alternate TCA configuration in the global T3_VAR array. The full path is $T3_VAR['EXT']['tagpack']['TCA']['alternate_config'][table_name]. If tagpack detects such a configuration, it will use it instead of the default one for the given table.

It's also possible to define the path as $T3_VAR['EXT']['tagpack']['TCA']['alternate_config']['default'] which will override the default configuration for all tables.

Example taken from the tagpack_altselector extension (file ext_tables.php), which overrides the configuration for the "pages" table:

    // Include class for custom field
require_once(t3lib_extMgm::extPath('tagpack_altselector', 'class.tx_tagpackaltselector_tceforms.php'));

    // Define alternate TCA configuration for tag selector
$alternateConfiguration = array(
                                'label' => $TCA['tx_tagpack_tags']['ctrl']['title'],
                                'exclude' => 0,
                                'config' => array(
                                    'type' => 'user',
                                    'userFunc' => 'tx_tagpackaltselector_TCEForms->selectorField',
                                )
                            );

    // Set the alternate configuration for the pages table
$T3_VAR['EXT']['tagpack']['TCA']['alternate_config']['pages'] = $alternateConfiguration;

Updated by Francois Suter over 3 years ago

Note that I didn't update the ChangeLog file, because it has an unusual structure, so I leave that to you.

Updated by Francois Suter about 3 years ago

Any plans of releasing a new version of tagpack? I have an extension that depends on these changes and I would quite like to publish it, but I don't want to have it depend on a dev version of tagpack. Also I would like to let my client know that he can safely use the public version of tagpack and not depend on a patched version.

Updated by Francois Suter almost 3 years ago

Raisin the topic again. Could we have a new version of tagpack, so that this feature is publicly available? If not, what is missing to allow for a new release to be made?

Updated by Francois Suter almost 3 years ago

Ping :-)

Updated by Claudio Strizzolo over 2 years ago

I agree with Francois' request: a new official version of tagpack should be released, IMHO.
I am waiting for a new public version before releasing some projects, because I do not want to depend on the patches released since the last official one.
Any plans about it?

Updated by Francois Suter over 2 years ago

  • Status changed from Resolved to Needs Feedback

I'm reopening this issue, because my commit was actually overridden in r30104 when trunk way synchronized with TER version.

May I re-commit my patch to trunk?

And of course, the usual question: any release planned in the near future?

Also available in: Atom PDF