I have a question regarding TYPO3 9 (and future versions) and PSR-15.
AFAIK most of the backend modules implement a handleRequest method for backend module controllers that have the same signature as PSR-15's RequestHandlerInterface.
Is it intended in future versions to implement this interface and does anything speak against implementing for my own backend modules?
I’m rebuilding an entire backend module for compatibility with TYPO3 9 and would like to be sure that such an approach is viable in future version s (at least until TYPO3 10).
The module itself worked for almost 10 years without any bigger overhaul, but with BaseScriptClass being deprecated, I see no other choice.
Thanks for your feedback.
Using requests and response is the way to go. This is nothing invented by TYPO3 but a standard which is implemented, see https://www.php-fig.org/psr/psr-15/. Stuff like GeneralUtility::_GET will be deprecated or even removed probably in version 10.
Getting back to your question: Yes use that in your backend modules! Currently the core tries to remove less extbase, especially in the backend because of various reasons and this is also the way to go for extensions. Check out e.g. the backend module of the redirects extension or site module. A custom extension I currently implement is https://github.com/georgringer/site_management which follows also those principles.
Related
I am using Drupal 8.9.15 (with composer and Docker).
The problem is that the vurenabilities dependency check tool detects about 200 issues and most of them are realted to Drupal, and most of them to jqueryui which is used by Drupal, for example:
/web/core/assets/vendor/jquery.ui/node_modules/grunt-html/vnu.jar/META-INF/maven/commons-fileupload/commons-fileupload/pom.xml
/web/core/assets/vendor/jquery.ui/node_modules/babel-core/node_modules/lodash/package.json
/web/core/node_modules/ftp/package.json
Why is it happening if Drupal is secure CMS?
Is it possible to fix it somehow? I see that the packages are downloading automatically to node_modules in drupal core directory.
This is unfortunately part of the reason that it's recommended to upgrade to Drupal 9 (believe me, the path is much better than from 7 -> 8).
It's known by the Drupal community that jQuery UI is no longer supported as mentioned in this change record. The recommended course of action is to upgrade to Drupal 9.
To answer your question, "Why is it happening if Drupal is secure CMS?" Well, it is as secure as it can be and as secure as its end users allow it to be. When Drupal 8 was released, jQuery UI was still supported. Now that Drupal 9 is released, jQuery UI is not part of core.
If you upgrade to Drupal 9, the security issues with jQuery UI will no longer be of concern.
Now, this is only for Drupal Core. There may still be some contrib modules that use jQuery UI elements, but that is not the responsibility of the core maintainers to watch for. However, as listed in the change record, they have mentioned a few contrib modules that still use those assets.
I'm writing a WordPress plugin. (However, this is not a WordPress-specific question - this challenge could arise in any PHP codebase which uses a plugin pattern.)
My plugin makes use of a popular third-party library, which is also used by a lot of other common WordPress plugins.
Obviously, if both my plugin and another plugin load their own copies of this library, PHP is going to throw an error, because I'm trying to redeclare an already-declared class.
How can I avoid this conflict? Before you answer, please consider why I've rejected these obvious options:
I could rename the library's classes, or put them in a new namespace. I don't like this because it involves modifying the library files. If I later need to upgrade to a newer version of the library, it would overwrite my modifications. And it's just generally an inelegant PITA.
Before my plugin actually includes the library, I could use class_exists() to make sure it hasn't already been included. There are two reasons I don't like this option:
Another plugin might use a different version of the library that has a slightly different API. This could cause my plugin, or the other plugin, to break (depending on which version of the library gets loaded first).
More importantly: the library in question contains multiple class definition files, and each child class includes its parent. Say that my plugin includes ChildClass1.php (which, in turn, includes BaseClass.php), and another plugin includes ChildClass2.php (which also includes its own copy of BaseClass.php). class_exists() doesn't help me here - there's no way that both plugins can include the ChildClasses they need without causing a conflict.
So: how can I make use of this library without running into one of these problems? Is there some way to override the library's namespace at include time (without modifying the library)? Is there some other solution that I'm overlooking? Seems like this must be a pretty common situation.
I'm answering my own question. (I can't believe I was this naïve only three years ago!)
This problem (among others) is exactly why dependency managers exist. (If you use npm, then you're already familiar with dependency management.)
In the PHP world, Composer is the standard tool for dependency management.
However, WordPress isn't really built to play nice with dependency managers (or with source control). In fact, WordPress actively fights against these practices.
There is a project called Bedrock, which tries to contort WordPress into something that's compatible with modern development practices. I haven't used it – but if you must use WordPress, it's worth investigating.
tl;dr:
The solution to this problem is to use a dependency manager, such as Composer.
But, WordPress simply isn't compatible with Composer – it'll fight you every step of the way, and you'll create more problems than you solve.
Unless you use Bedrock's version of WordPress – which is designed to work with Composer.
But, at that point, you might as well ditch WordPress, and adopt a CMS platform that's sanely engineered in the first place – and doesn't have to be twisted and tortured into cooperating with industry-standard practices.
Just I have one doubt that why one component or module is compatiable with one version of Joomla(Ex-> Joomla 2.5) but the same component or module is not compatiable with another version of Joomla(Ex-> Joomla 3.0).
If I want to make it compatiable with another versions also then what changes I need to do
The problem with compatibility is Joomla! is a delicate one.
The Joomla! platform / API is evolving all the time (especially between LTS releases like 1.5 and 2.5), so classes / functions are changed or deprecated and later removed. New things are added and so on.
For developers is possible to maintaing a component under different versions (I am not saying it's easy), but they need to know what has changed in the API.
Also constructs like (in pseudocode)
if (Joomla! version == 1.5) then do this else do that.
are used to make sure some parts of the code are used only in a specific version.
To better understand what is going on have a look at:
Potential backward compatibility issues in Joomla 3.0
You you easily see:
Renamed classes
Removed classes
etc.
I have a kohana script which the customer wants to use in conjunction with a number of zen-cart modules. One idea I had was to run that script and zen-cart side by side with this class.
http://www.phpclasses.org/package/4912-PHP-Manage-users-of-Zencart-installation.html
Has anyone used this before? Is this a viable option? If not my options are port zen-cart modules to kohna (ugh) or rewrite the kohana script in zen-cart (double ugh).
I would think a much easier path would be to create a model for the Zencart customer object using the in-built ORM module in Kohana. Although all this depends on what your current Kohana script does. Can you post the code for your Kohana script, or at least provide an overview of it's functionality?
Porting a Zencart module to Kohana would be a better option because:
Kohana is a much better framework than the mess that is Zencart.
You can release that ported code to the community to allow other developers to take advantage of it (and improve your code).
I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7