There are 2 functions in TYPO3 which seem to more or less do the same:
ExtensionManagementUtility::addModule
/**
* Adds a module (main or sub) to the backend interface
* FOR USE IN ext_tables.php FILES
ExtensionUtility::registerModule
/**
* Registers an Extbase module (main or sub) to the backend interface.
* FOR USE IN ext_tables.php FILES
So, according to the comments, they basically do the same, but one registers and one adds and for one it's an Extbase module. I have seen examples for both online and seen TYPO3 extensions use one or the other methods.
Which of these methods should be use to create a TYPO3 backend-module and what is the difference?
I can just use one or the other methods, but I would like to get some more guidance on these general things and what is the best practice for the future.
The obvious answer is probably, if you use Extbase, you use registerModule, if not, you use addModule. Ok, but then, why does the core do it this way in some cases and that way in the other?
Another obvious answer is that registerModule calls addModule.
See also this comment.
With addModule you just add a new Module into the left navigation bar.
With registerModule you do some pre-configuration for extbase. Have a look into the code, all controller->action combinations will be registered globally. A vender will be set and please have a look at the very last line: It calls addModule from above.
Additionally, it looks like ExtensionUtility::registerModule() is used for modules based on Extbase, and ExtensionManagementUtility::addModule() otherwise (see BackendModuleApi)
Related
Im upgrading an extension to work with TYPO3 v10. Since command controllers can not be used anymore, im migrating them to symfony commands as pointed by the documentation. Everything works smooth as heck except for the usage of extbase repository classes. No matter what i query, i never get a result. Since i can't find any useful information on the web and the documentation i hope this may be just something minor.
After debugging for a while i found out that the pid is not determined correctly while building the query settings. I find that kind of strange since my root template has these lines:
plugin.tx_myext.persistence.storagePid = 15403
module.tx_myext.persistence.storagePid = 15403
The repository instances are correctly injected by injectMyRepository() methods. I've tried using the extbase ObjectManager to fetch the class instances instead but the "error" stays the same.
Am i doing something wrong or is it not possible to use extbase repository classes in symfony commands?
After more research i found out that there is some bootstraping missing which results in extension settings (the storageID in my case) not being loaded. From what i've been reading, that behaviour seems intended to prevent extbase booting, i guess?
There is a reference to something similiar in the official documentation: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/CommandControllers/Index.html#initialize-backend-user
Knowing that, i tried to find a method to initialize the missing settings which i could not find. So this does indeed seem like a missing feature.
I developed a workaround which i'm not too proud of, but it's better than nothing (or rebuilding everything to doctrine for that matter). If you stumble upon the same issue, here you go. Just insert and call this method before you fire your query:
public static function initializeConfigurationManager(): void
{
/** #var ConfigurationManager $configurationManager */
$configurationManager = GeneralUtility::makeInstance(ConfigurationManager::class);
$tmpConfiguration = $configurationManager->getConfiguration(
ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK,
'myExtensionName'
);
$configurationManager->setConfiguration($tmpConfiguration);
}
That approach exploits the singleton state of the ConfigurationManager. You simply inject the static template of your extension manually and every extbase compound (like repositories) will then use these settings from there on. Lovely.
Be aware however, this is prone to break with future internal changes.
The common way to write the TypoScript is in Configuration/TypoScript/setup.txt.
But there also two other way to write TS. One with ext_typoscript_setup.txt and other with ExtensionManagementUtility::addTypoScriptSetup().
Can someone explain me what the difference is and when should i use which one?
Theoretically the usage of ext_typoscript_setup.txt files has been deprecated. Theoretically because it has never really been removed from the core.
ext_typoscript_setup.txt and ExtensionManagementUtility::addTypoScriptSetup() do quite the same thing as those will always load the given TypoScript. However the problem is that sometimes people have a hard time overriding those default code. To make it even more complicated there is the select field Static Template Files from TYPO3 Extensions inside the sys_template record which can influence the order.
As a solution (or at least how I handle it):
Always use the way of having TS in Configuration/TypoScript/... and let the integrator decide how and in which order it is included. Some people include TypoScript within their SitePackage, some in sys_template record, ...
However I also use ext_typoscript_setup.txt in rare case if some TS must be available and which won't be changed by an integrator.
I implement MyClass containing the method method() and I store the instance in $_ENV['key'] in test.php. Also in test.php the code completion works when I type $_ENV['key']->.
In test2.php I include test.php and the code completion does not work any more for $_ENV['key']->.
Does anyone know how to enable this in PhpStorm?
AFAIK type tracking for arrays works within the same file only.
You can bypass it via intermediate variable (yes, it's not a nicest solution) and small PHPDoc comment, like this:
/** #var MyClass $myVar */
$myVar = $_ENV['key'];
$myVar->
P.S.
In general, I'd suggest not using global arrays this way (or even not using global vars at all -- only very basic stuff during bootstrap, if possible). Instead (based on your code) I may suggest using some static class (as one of the alternatives) with dedicated field where you can easily give type hint (via PHPDoc) to a class field -- this way IDE will always know hat type it is. Current PHP versions (5.5 and especially 5.6) work with objects nearly as fast as with arrays, even leading in (smaller) memory consumption.
Obviously, such suggestion does not really apply if this code is not yours.
i am struggling a little challenge and i am wondering what the solution might be as I couldn't find an answer in the documentation.
Here is my current working query (part):
$constraints[] = $query->like('kategorie', '%'.$kategorie.'%');
What I want to do is something like:
$constraints[] = $query->like(CONCAT(',', kategorie, ','), '%,'.$kategorie.',%');
Which obviously doesn't work at all. : -)
Every Help is really appriciated. Hope someone know the right syntax. TYPO3 Version is latest 6.1
Thank's alot!
First of all, Extbase query generation didn't change in 6.0, so it's the same for 4.x and 6.x.
Maybe you misunderstand the way Extbase is builing the query.
$query->like('property', '%value%');
will return an object when %value% is contained in "property". Such a property must be defined in the domain model. You can only query properties that have a "getProperty" method in their domain model.
Looking at your code, I think you're finding a way to query for a value being present in a comma-separated value list? Then you would use
$query->in('kategorien', $kategorie);
EDIT:
Your specific problem seems to be that you are not using a true relation for assigning "Kategorien" to your entity. You're using a comma-separated list to hold references to another model. You're discouraged to do so, but it is technically possible and used in the TYPO3 core: The FrontendUser model has a property "usergroup" that works in the same way.
Please have a look at the FrontendUser model: https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/extbase/Classes/Domain/Model/FrontendUser.php
The annotation of your Kategorien must be correct, e.g.:
/**
* #var \TYPO3\CMS\Extbase\Persistence\ObjectStorage<\My\Extension\Domain\Model\Kategorien>
*/
protected $kategorien;
Also make sure that getKategorien is correct.
If you still have problems, keep in mind that the TCA definition must be working to have Extbase work correctly.
In my opinion, a best practise would be to use the category API introduced in TYPO3 6.0:
http://wiki.typo3.org/TYPO3_6.0#Category
Just installed rails 3.1 rc1 and am trying to grok the best way to manage javascript with the new asset pipeline
By default all coffeescript is compiled into a single application.js file, this is a good thing.
Each seperate coffee script file is appended to the js file and wrapped in an anonymous function which is executed via the call method
A common scenario would be to use some jquery to turn various forms into ajax forms, update UI, etc...
Many of these scripts will be specific to a controller or action, I am trying to grok the 'conventional' way to handle this,
since everything is wrapped in an anonymous function how do I only execute just
the code for a particular controller / action, by default all of the anonymous functions are being executed
I did play around with some hacks where I load the controller and action name into js variables and then in
coffeescript check those to conditionally run code, I don't like that very much
my initial thought was that each coffee file would contain a js namespace/object and I would call the specific ones from the view,
going to spike this using the default_bare = true configuration
see How can I use option "--bare" in Rails 3.1 for CoffeeScript?
EDIT
Looking around some more: this looks like it might be the correct approach - "Can't find variable" error with Rails 3.1 and Coffeescript
There are two common approaches:
Make behavior conditional on the presence of a particular element. For instance, code to run a signup sheet should be prefaced with something like
if $('#signup').length > 0
Make behavior conditional on a class on the body element. You can set the body class using ERB. This is often desirable for stylesheets as well. The code would be something like
if $('body').hasClass 'user'
gistyle is a simple gem that helps you running action-specific javascript codes.
By following its setup, you set some data attributes in your body element, representing the current controller and action names. Then it will only call that action when the corresponding view is loaded.