Icon size of imageorient selection - typo3

I have extended the imageorient selection with some additional options:
TSconfig:
TCEFORM.tt_content.types.textmedia.addItems{
101 = XL Image
101.icon = img_xl
# …
}
The new icons are already registered via the Icon API in a sitepackage.
ext:sitepackage/Configuration/Icons.php
<?php
return [
'img_xl' => [
'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
'source' => 'EXT:sitepackage/Resources/Public/Icons/Content/img_xl.svg',
],
'mybitmapicon' => [
'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\BitmapIconProvider::class,
'source' => 'EXT:sitepackage/Resources/Public/Icons/Content/test.png',
],
];
It looks like this:
They are displayed with 16x16 pixels, no matter how big they actually are (I tried it with svg and png of different sizes).
Since some are a bit more complex than the standard icons, I would like to make them larger.
Whether the standard icons scale is not important.
Is there any way to influence the output size?
In the TCA Reference it looks like this could be possible, since the example has larger images shown. Probably the TCA would need to be modified via ext:sitepackage/Configuration/TCA/Overrides/tt_content.php, but it's unclear to me how exactly.

These icons are rendered in SelectIcons::render() (Code) using the FormEngineUtility::getIconHtml()-function (Code).
The rendering depends on the icons declaration:
Icons as file-reference
The Icons are rendered without width/height attributes in HTML. So, it should be possible to use them sized as you want.
Sprite Icons name
The icons are finally rendered by calling IconFactory::createIcon (Code) with a fixed size of 16px (Icon::SIZE_SMALL= 'small' // 16).
On a simple way via configuration, another size won't (currently) be possible.

Related

How can I display the material-ui theme object in storybook

I would like to display our theme object in storybook somehow but haven't found a way to even look at theme from inside a component.
Minimally I would like something like what material-ui does showing the theme structure here: https://mui.com/customization/default-theme/
Idealy I would like to map through parts of the object and display colors, font sizes, font weights, spacing etc kind of like this (but it doesn't work because you can't access the theme like this)
const useStyles = makeStyles((theme) => theme.palette.primary);
export const Primary = (): JSX.Element => {
const classes = useStyles;
return (
<>
{Object.keys(classes).map((key) => <Box bgcolor={classes[key]}>{key}</Box>)}
</>
)
};
As the mui.com website is open source, you can implement the minimum by copying the source for the theme explorer on the Default Theme page. You can see how they traverse the theme object, similar in a way to your code snippet.
If you only want to highlight parts of the theme file, you can traverse the object and use some inbuilt components like ColorPalette from #storybook/addon-docs for example. In the MUI project on the palette page, they manually pull out each color using useTheme().
Maybe an storybook addon might be better placed? Example usage with MUI at the bottom of the page: https://storybook.js.org/addons/#react-theming/storybook-addon/

New custom content element on typo3 with a select option

I want to create a content element where the editor can chose an icon to display on the frontend.
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTcaSelectItem(
'tt_content',
'CType',
[
'LLL:EXT:your_extension_key/Resources/Private/Language/Tca.xlf:yourextensionkey_newcontentelement',
'ServiceCE',
'example-registration',
],
'textmedia',
'after'
);
$GLOBALS['TCA']['tt_content']['types']['ServiceCE'] = [
'showitem' => '
--div--;LLL:EXT:core/Resources/Private/Language/Form/locallang_tabs.xlf:general,
--palette--;;general,
header; Header,
bodytext;LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:bodytext_formlabel,
',
];
Here I'm creating the layout on the back-end to insert the content, with just a header and a bodytext.
There would be a lot of possible solutions:
dependent whether the icon should be assigned to pages or content elements work with the table pages or tt_content
your extension will provied the list of icons:
add an additional field with a select list for the icons to the records. put it into TCA (Configuration/TCA/Override/<table>.php). Make sure the value is the icon-name, so you do not need additional replacements in FLUID.
Add the rendering to the FLUID template where it belongs. As it should be available everywhere the Layout-templates would be a good place.
use sys_categories:
use the build in categories for providing icons to any record.
create some categories with either the icon as category image or use another field as the icon name. (You even could add another field especially for the icon name.)
For the rendering of pages or tt_content add a data processor to get the assigned sys_category-records of the data record and then render the first/all icon(s) of the record in the Layout-templates.

Generate TYPO3 cropVariants for images from CLI

Is there a way to trigger the generation or update of cropVariants for existing image relations?
My use case: I want to make sure that images always obey a certain aspect ratio. Thus, I have defined a cropVariant called "myCropVariant" for images, for example in pages and some custom tables. This basically works fine, I see a new wizard in the "create image relation" dialog where I can select the cropArea, and even if I don't click on that wizard, the cropVariant image along with the cropVariant database record is created as soon as I save the parent record, using the center of the image as the crop area. Frontend output also works fine using
<f:image cropVariant="myCropVariant"/>
The problem is: I imported a lot of content from another website into the database (using a custom migration CLI command). That also includes images; I've created the corresponding sys_file records and references. The images are rendered fine in frontend, but the cropVariant is not being used. That's because it doesn't exist in database because nobody has clicked through the imported content in backend. Now creating them through the migration script from outside TYPO3 would in theory be possible, but would be pretty nasty (because one needs to know the image dimensions and so on), so I look for a best practice for this through TYPO3 by CLI or something similar.
// get crop variant conf directly from TCA
$cropVariants = $GLOBALS['TCA']['tx_myext_domain_model_example']['columns']['attachments']['config']['overrideChildTca']['types'][2]['columnsOverrides']['crop']['config']['cropVariants'];
// extend for default cropArea configuration
foreach ($cropVariants as &$variant) {
$variant['cropArea'] = ['x' => 0.0, 'y' => 0.0, 'width' => 1.0, 'height' => 1.0];
}
// init variants
$cropVariantCollection = CropVariantCollection::create('', $cropVariants);
// apply configuration to TYPO3\CMS\Core\Resource\File
$processedCollection = $cropVariantCollection->applyRatioRestrictionToSelectedCropArea($file);
// get json string from variants ({"desktop":{"cropArea":{"x":0,"y":0.125,"width":1,"height":0.75},"selectedRatio":"16:9","focusArea":null}})
$cropValue = (string)$processedCollection;
// save e.g. via dataHandler to sys_file_reference

Socialengine default layout change has no effect

I am using socialengine 4.2.I added some markup in Core\layouts\scripts default-simple.tpl and default.tpl but nothing seems to have an effect on front-end,even after flushing.I want to put a banner slider,for which I dont want to make a widget and put it on global header.I need to add some esternal scripts and css in the default layout,I guess, and then some markup in body.
1.I want to know,if need be, how to edit default layout.
2.Whats the difference between default-simple.tpl and default.tpl
1) Yes, you can edit layouts directly, and it works. Need more details how you tried it. And you can look into SE4 hooks (yes, more flexible and more complex way).
default.tpl:
echo $this->hooks('onRenderLayoutDefault', $this);
2) default-simple.tpl is auxiliary layout, it used for post-action messaging mostly, see Forum_TopicController::deleteAction() for example:
return $this->_forward('success', 'utility', 'core', array(
'messages' => array(Zend_Registry::get('Zend_Translate')->_('Topic deleted.')),
'layout' => 'default-simple',
'parentRedirect' => $forum->getHref(),
));

Why does the '#weight' property sometimes not have any effect in Drupal forms?

I'm trying to create a node form for a custom type. I have organic groups and taxonomy both enabled, but want their elements to come out in a non-standard order. So I've implemented hook_form_alter and set the #weight property of the og_nodeapi subarray to -1000, but it still goes after taxonomy and menu. I even tried changing the subarray to a fieldset (to force it to actually be rendered), but no dice. I also tried setting
$form['taxonomy']['#weight'] = 1000
(I have two vocabs so it's already being rendered as a fieldset) but that didn't work either.
I set the weight of my module very high and confirmed in the system table that it is indeed the highest module on the site - so I'm all out of ideas. Any suggestions?
Update:
While I'm not exactly sure how, I did manage to get the taxonomy fieldset to sink below everything else, but now I have a related problem that's hopefully more manageable to understand. Within the taxonomy fieldset, I have two items (a tags and a multi-select), and I wanted to add some instructions in hook_form_alter as follows:
$form['taxonomy']['instructions'] = array(
'#value' => "These are the instructions",
'#weight' => -1,
);
You guessed it, this appears after the terms inserted by the taxonomy module. However, if I change this to a fieldset:
$form['taxonomy']['instructions'] = array(
'#type' => 'fieldset', // <-- here
'#title' => 'Instructions', // <-- and here for good measure
'#value' => "These are the instructions",
'#weight' => -1,
);
then it magically floats to the top as I'd intended. I also tried textarea (this also worked) and explicitly saying markup (this did not).
So basically, changing the type from "markup" (the default IIRC) to "fieldset" has the effect of no longer ignoring its weight.
This sounds pretty strange because the manipulation of the form elements' #weight parameter always works reliably for me as advertised. One thing to note, though, is that the weights only affect the order relative to the elements siblings, so if the element you want to move around is on a level below that of the other elements, you'd have to change the weight of the parent element that is on the same level as the ones you want to move against.
To clarify, if you have a hierarchy like so,
$element['foo'];
$element['bar'];
$element['bar']['baz']
you can not move 'baz' relative to 'foo' by setting the weight of 'baz'. You'd have to either set the weight on 'bar' (moving it also), or pull out 'baz' and bring it to the same level as 'foo'.
Another possible reason could be CCK: If you have CCK installed, it allows you to set the order of its own as well as other fields under admin/content/node-type/<yourNodeType>/fields. It changes the order by registering the pre-render callback content_alter_extra_weights(), so this would run after your changes in hook_form_alter.
Edit: Update to answer the question update
The markup field type has a special behavior when used inside fieldsets, which is hinted on in the forms api documentation:
Note: if you use markup, if your content is not wrapped in tags (generally <p> or <div>), your content will fall outside of collapsed fieldsets.
It looks like if it does not only fall outside of collapsed fieldsets, but also refuses to respect the weight in those cases. Wrapping the content of the markup field in <p> tags makes it respect the weight on my machine:
$form['taxonomy']['instructions'] = array(
'#value' => "<p>These are the instructions</p>",
'#weight' => -1,
);
Sometimes (or always, when weighting CCK elements) the line that works in your hook_form_alter or $form['#after_build'] callback is this one:
$form['#content_extra_fields']['taxonomy']['weight'] = 5;
Wanted to insert a <div> I could use in JS. This didn't work for me:
$form['you_as_reviewer']['ui_container'] = array(
'#type' => 'markup',
'#value' => '<div id="le_reviewer_tags_ui"/>',
'#weight' => 5,
);
Weight was ignored.
This worked:
$form['you_as_reviewer']['ui_container'] = array(
'#type' => 'markup',
'#prefix' => '<div>',
'#value' => '<div id="le_reviewer_tags_ui"/>',
'#suffix' => '</div>',
'#weight' => 5,
);
Added prefix and suffix.
I do not quite understand what it is you want to achieve. Could you maybe clarify? Do you want to change the position of the taxonomy's drop-down on the page?
In the mean time you could install the Drupal Devel module (if you haven't done so yet). Then enable "Display form element keys and weights" from Admin > Devel Settings.
This should help you to debug your problem.
Edit after feedback:
I looked into it some more. The taxonomy weight is set in taxonomy.module on line 556 (Drupal 6.12):
$form['taxonomy']['#weight'] = -3;
To test I also implemented hook_form_alter for my module like this:
function mymodule_form_alter(&$form, $form_state, $form_id) {
...
$form['taxonomy']['#weight'] = -9;
...
}
This works for me i.e. it moves the taxonomy drop-down to the top of the page. I can change the weight and it moves accordingly on the rendered page.
Since you said you tried setting $form['taxonomy']['#weight'] in your original post I can currently think of only two possible checks:
Make sure the cache is cleared before testing. (you can use the Devel module for this)
Check to see if your hook_form_alter is called after taxonomy_form_alter
I you post the code you currently have we could look at it in more detail.
Please note: the weights displayed by the Devel module are not very useful for this situation. The weights of the elements on the "sub-forms" are displayed and not the weight of the "sub-form" itself. E.g. when I set $form['taxonomy']['#weight'] = -9; the -9 is not displayed by the Devel module but rather the weights of the elements inside $form['taxonomy'].
Have you specified the weight of another field and now your node form is not organized properly? The form api is kinda touchy and altering the form can result in things getting mixed up. I sometimes have to reassign a weight to my submit/preview buttons to get them back at the bottom of the form where they belong.
Just to cover all bases, make sure that you are clearing your cache as necessary. Drupal stores forms in it's cache by default, if you have the caching module enabled.
This is working for me
$form['forgot_password']['#markup'] = '<div class="text-align-right"><a class="text-primary" href="/user/password" target="_blank" title="Forgot Password?">Forgot Password?</a></div>';
$form['forgot_password']['#weight'] = 3;