We're trying to use a legacy pibase extension that worked in a TYPO3 6.1 installation in a TYPO3 7.6 environment. We installed the compatibility6 extension.
The pibase extension basically works, but something (TM) seems to call the pibase main() method twice; this confuses a bit of the internal workings of the extension, because static counters do not start fresh.
We found out that tt_news has the same problem, it is executed twice and thus can lose pagination properties.
Might this be an issue of the compatibility6 extension, or within the TYPO3v7 core? We couldn't easily deduce where exactly the first call happens (the output is actually created in the second main() call).
The solution was actually that in typoscript we added multiple calls to get the content:
page.10.variables {
main_content < styles.content.get
main_content.select.where = colPos = 0
another_content < styles.content.get
another_content.select.where = colPos = 0
}
We needed to rewrite this to specifically only get the main content once. Maybe this helps someone with a similar problem.
Related
I inherited an old TYPO3 Extension using SOBE. As far as I unterstand it's deprecated, but it seems there is no documentation on how to replace it.
The Extension is using Backend Forms and the following line is throwing an error:
if (is_array($GLOBALS['SOBE']->editconf['tt_content']) && reset($GLOBALS['SOBE']->editconf['tt_content']) === 'new') {
The error is:
Cannot access protected property TYPO3\CMS\Backend\Controller\EditDocumentController::$editconf
The Var $GLOBALS['SOBE'] is still there, and there is also editconf, but it's not working.
How can I replace this code or rewrite it?
The SOBE object is part by part removed since years. As there are multiple ways for using it - see https://docs.typo3.org/c/typo3/cms-core/main/en-us/search.html?q=sobe&check_keywords=yes&area=default - you may need to take a closer look what is the exact part of replacing this code.
I would guess you can see more at https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/9.2/Deprecation-84195-ProtectedMethodsAndPropertiesInEditDocumentController.html?highlight=editconf.
My plugin configuration looks like this;
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin('Orbit.Navigator', 'mission', [
\Orbit\Navigator\Controller\SpaceXController::class => 'cpt, cpr, shuttle',
\Orbit\Navigator\Controller\Conf\FlightController::class => 'pressure,target,timer',
\Orbit\Navigator\Controller\Conf\WeatherController::class => 'mav,hub',
]);
I have this setup,
10 = USER_INT
10 {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
extensionName = Navigator
pluginName = mission
vendorName = Orbit
switchableControllerActions {
SpaceX{
1 = shuttle
}
}
}
The request lands in the shuttleAction() method in SpaceXController. After processing, How do I FORWARD it to timerAction() in FlightController?
Using;
$this->forward('timer', 'Flight', $this->request->getControllerExtensionName(), $this->request->getArguments());
acts like $_POST and results in;
(1/2) #1278450972 TYPO3\CMS\Extbase\Reflection\Exception\UnknownClassException
Class does not exist. Reflection failed.
Using;
$this->redirect('timer', 'Flight', $this->request->getControllerExtensionName(), $this->request->getArguments());
acts like $_GET (redirects to another page) and page throws an error complaining of "too many redirects".
Am able to forward to another action in the same Controller but how do I forward to another action in another Controller?
So it turns out that switchableControllerActions is being deprecated for the very reasons mentioned above. It override the original configuration of plugins at runtime. But am thankful I won't be relying on that setting. Although the deprecation notice mentions this, it further states that they're removing it for not adhering to it's paradigm for plugins. To quote from the deprecation notice thusly,
switchableControllerActions have been marked as deprecated and will
be removed in one of the next major versions of TYPO3, probably
version 11.0 or 12.0.
switchableControllerActions are used to override the allowed set of
controllers and actions via typoscript or plugin flexforms. While this
is convenient for reusing the same plugin for a lot of different use
cases, it’s also very problematic as it completely overrides the
original configuration defined via
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin.
switchableControllerActions therefore have bad implications that
rectify[sic] their removal.
First of all, switchableControllerActions override the original
configuration of plugins at runtime and possibly depending on
conditions which contradicts the idea of
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin being the
authoritative way to define configuration.
Using the same plugin as an entry point for many different
functionalities contradicts the idea of a plugin serving one specific
purpose. Switchable controller actions allow for creating one central
plugin that takes care of everything.
Source: Deprecation: #89463 - Deprecate switchableControllerActions
I for one completely agree it's a good move.
There's a way around it that is made possible by TYPO3's capacity for multiple plugin definitions in the extension configuration file (ext_localconf.php) of a single extension. With that, one can define a dedicated plugin for any individual action needed in TypoScript or FlexForm.
I need to include a PHP script in my TS template :
page {
10 = USER_INT
10.includeLibs = lib_confidential.php
10.userFunc = MyClass->ConfidentialRequest
}
It works perfectly but I would like to locate the lib_confidential.php outside of my website root directory (and make something like 10.includeLibs = ../lib_confidential.php). Is it possible to secure my PHP script and how to ? I thought about creating a symlink but that doesn't give any solution.
As your installation needs an update you will have to change the mechanism for including php-functions for the future.
since TYPO3 8 you need to have a class for your php functions. So the autoloader can identify the class and execute the function you need to place the class inside of an extension or declare the class to the autoloader.
Best practice would be site extension where you configure your installation, there you can havea class with all the functions you need.
examples can be found in the manual.
Given you are in a BE or CLI context (e.g. sending emails via extbase command controller task), the following worked up to 7 LTS for rendering a fluid standalone view:
$view = $this->objectManager->get(StandaloneView::class);
$view->setTemplatePathAndFilename('/Absolute/Path/To/Template.html');
$view->setFormat('html');
$view->getRequest()->setControllerExtensionName('Myextensionname');
return trim($view->render());
However, in 8 LTS, this throws the following exception:
Tried resolving a template file for controller action "Standard->index" in format ".html", but none of the paths contained the expected template file… No paths configured.
As suggested in the wiki page at https://wiki.typo3.org/How_to_use_the_Fluid_Standalone_view_to_render_template_based_emails#Usage_in_TYPO3_8.7, I tried setting layout and partial root paths for the view:
$view->setLayoutRootPaths(['EXT:Myextensionname/Resources/Private/Layouts/']);
$view->setPartialRootPaths(['EXT:Myextensionname/Resources/Private/Partials/']);
However, this won't do the trick.
Digging a bit deeper, I could imagine that one would have to set the controller and action name, e.g. by setting the controller context, but that does not seem to be a solid solution as multiple other class instances are tied to it.
What is the correct way to render fluid standalone views in 8 LTS?
Here an example from our current webproject where we want to show a simple note in backend context based on a FLUID HTML in TYPO3 8.7
protected function renderMarkup(): string
{
$standaloneView = GeneralUtility::makeInstance(StandaloneView::class);
$standaloneView->getRequest()->setControllerExtensionName('in2template');
$templatePathAndFile = 'EXT:in2template/Resources/Private/Templates/Tca/ToolbarNoteEmptyFields.html';
$standaloneView->setTemplatePathAndFilename(GeneralUtility::getFileAbsFileName($templatePathAndFile));
$standaloneView->assign('toolbar', 'toolbarstuff');
return $standaloneView->render();
}
StandaloneView likes to receive all template paths (partial, template and layout root paths) so if you don't already provide all of them, you should do so. The reason being that the naming "Standalone" refers to the view being tied neither to a specific MVC action nor a specific extension context.
That said, if you use 8.7.5 there's a chance you are hit by a regression that is going to be solved by https://review.typo3.org/#/c/53917/ so it might be worth checking that out before you do a major refactoring. Technically the StandaloneView can be operated like a TemplateView with extension context, it's just not officially supported behavior and TYPO3 may not consistently apply all of the context you expect.
In my 8.7 extension I use the following code to get the StandaloneView:
$extbaseFrameworkConfiguration = $this->configurationManager->getConfiguration(ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
/** #var StandaloneView $emailView */
$emailView = $this->objectManager->get(StandaloneView::class);
$emailView->getRequest()->setControllerExtensionName($controllerExtensionName);
$emailView->getRequest()->setPluginName($pluginName);
$emailView->getRequest()->setControllerName($controllerName);
$emailView->setTemplateRootPaths($extbaseFrameworkConfiguration['view']['templateRootPaths']);
$emailView->setLayoutRootPaths($extbaseFrameworkConfiguration['view']['layoutRootPaths']);
$emailView->setPartialRootPaths($extbaseFrameworkConfiguration['view']['partialRootPaths']);
$emailView->setTemplate('Email/' . ucfirst($templateName));
$emailView->assignMultiple($variables);
$emailBody = $emailView->render();
In my function I gave the $controllerExtensionName, $pluginName and $controllerName as parameter with default values, so that other controllers/plugins can use this function, too.
I am getting this error after adding to an extension a class from another extension:
Uncaught TYPO3 Exception
#1247602160: Table 'deva.tx_bingoprizes_domain_model_hall' doesn't exist: SELECT tx_bingoprizes_domain_model_hall.* FROM tx_bingoprizes_domain_model_hall WHERE tx_bingoprizes_domain_model_hall.uid IN ('0') LIMIT 1
Tx_Extbase_Persistence_Storage_Exception_SqlError thrown in file
/home/typo3_src/typo3_src-4.5.32/typo3/sysext/extbase/Classes/Persistence/Storage/Typo3DbBackend.php in line 1008.
The class added is tx_bingoprizes_domain_model_hall which should be reading from the table tx_bpscore_domain_model_hall as I added to the setup file:
config.tx_extbase.persistence.classes {
Tx_Bingoprizes_Domain_Model_Hall {
mapping {
tableName = tx_bpscore_domain_model_hall
}
}
}
as I did for other extension which also reuses this class and which works properly ( I use it as my model for how to do this and as near as I can tell did everything the same way ). Why is typo3 still trying to use table tx_bingoprizes_domain_model_hall? where else do I need to specify the other table? I tried restarting the server, clearing caches, reinstalling the extension but still get the error.
I am using the latest 4.5 typo3.
Thanks
to reiterate my comment as the answer...
OK, I got it. Once again I had forgotten to INCLUDE the necessary item (in this case bingoprizes) to the page's template. So the error was not in my extension but in the typo3 config for the page. I hate that, forget it all the time, it is counter-intuitive to me as I find it natural to assume the setup.txt stuff is auto included on any page that uses my extension.