Open cblanken opened 7 months ago
What an ambitious PR! :open_mouth: Thank you for getting on with this task.
I assume named parameters are still in use for some routes
Named parameters used to be the default for CakePHP < 3. They were used on Tatoeba for every page before. For example, if you look at this old archived page, you can see the "next page" links have a /page:2
parameter (as opposed to ?page=2
). CakePHP 3.x changed that default, we also did, but we did not want to break existing links, so just to keep backward compatibility we use parseNamedParams()
. You can try opening https://tatoeba.org/fr/sentences_lists/show/724/page:2 and you’ll see it still brings you to page 2 (a redirect would have been better though :pensive:). That’s the only reason.
(a redirect would have been better though 😔). That’s the only reason.
Do you think it'd be best to inline the parseNamedParams()
function from CakePHP 3.x? Otherwise this might be a good opportunity to stop supporting named parameters. If someone with access to the server could check the logs, there may not even be any recent usage of links with named parameters. In that case it'd probably be best to remove completely since they won't be supported by CakePHP in the future.
As far as I know we only keep logs for a short time so they probably won't give a good overview of old links usage. To keep maintaining old links or not to and potentially break things, that is the question! Personally I'm in favor of keeping old links working as long as it's not a burden (which I don't think it is, I mean it's fine to keep our own copy of parseNamedParameters()
). I don't think anybody likes getting 404 errors when browsing the web.
Okay, I've done what I can with this, but I don't think I'm familiar enough with CakePHP to sort out what's remaining. I've documented the changes as well as I could with links to the appropriate migration guide pages.
Maybe I'll return to it once I've worked with the codebase a bit more, but for the time being, anyone else who wants to pick this up is welcome to it.
[!NOTE]
When advancing the application to 4.x with the upgrade tool, be aware that PHP 8.x is required to run the tool, even though 4.x applications only have a minimum requirement of PHP 7.2. For more details, see https://book.cakephp.org/4/en/appendices/4-0-upgrade-guide.html#upgrade-to-php-8-0.
Thank you very much for working on this, @cblanken!
This isn't anywhere near complete, but I wanted to get the ball rolling on issue #3067 to upgrade to CakePHP 4.x since 3.x is EOL.
Progress
I've been following the CakePHP 4.0 Upgrade Guide. It has a few steps:
Edit: I've tried to match these to individual commits mostly, so it should be apparent where each deprecation is resolved, but this is a high-level overview of all deprecations that need attention.
$config
is deprecated. Configurations files should instead return an array. See https://book.cakephp.org/3/en/appendices/3-0-migration-guide.html#configureHelper::$request
as a property is deprecated as of CakePHP 3.7. The getterHelper->getRequest()
should be used instead. See https://book.cakephp.org/3/en/appendices/3-7-migration-guide.html#deprecationsRequest::param()
is deprecated as of 3.4. UseRequest::getParam()
instead. See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.html#request-response-deprecationsparams
as a property will be removed in 4.0.0. Use request->getParam() instead See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.html#request-response-deprecations.FormHelper::input()
is deprecated. UseFormHelper::control()
instead. See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.html#other-deprecations.FormHelper::create()
should takenull
instead of astring
orbool
as the context when creating contextless forms. See https://book.cakephp.org/3/en/appendices/3-9-migration-guide.html#deprecations.Cake\Controller\Component\SecurityComponent::config()
is deprecated. UsesetConfig()
/getConfig()
instead. I couldn't find the exact version this deprecation happens, but the SecurityComponent page here (https://book.cakephp.org/3/en/controllers/components/security.html) impliesSecurityComponent::config()
is deprecated after 3.4Query::repository()
as getter is deprecated. UsegetRepository()
instead See https://book.cakephp.org/3/en/appendices/3-6-migration-guide.html#deprecations for details.EventManager::attach()
is deprecated. UseEventManager::on()
instead See https://api.cakephp.org/3.0/class-Cake.Event.EventManager.htmlparseNamedParams()
is deprecatedwithParam()
instead See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.htmldata
as a property will be removed in 4.0.0. Use request->getData() instead. See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.htmlPlugin::load()
is deprecated. UseApplication::addPlugin()
instead. This method will be removed in 4.0.0 See https://book.cakephp.org/3/en/appendices/3-7-migration-guide.html#testsuite Note: there are only a few instances of this deprecation. Specifically in the tests, so I elected to use theTestCase::loadPlugins()
method instead ofApplication::addPlugin()
.ValidatorAwareTrait::validator()
is deprecated. Use ValidatorAwareTrait::getValidator()/setValidator() instead. See https://book.cakephp.org/3/en/appendices/3-5-migration-guide.html#validationApp\Model\Entity\Export::errors()
is deprecated. Use setError()/getError() or setErrors()/getErrors() instead. See https://github.com/cakephp/cakephp/blob/571fb867995ccfa4034ec5b66577f0ab2acd4429/src/Datasource/EntityInterface.php#L188Validator::errors()
is deprecated. Renamed toValidator::validate()
. See https://book.cakephp.org/3/en/appendices/3-9-migration-guide.html#deprecationsApp\Model\Table\ExportsTable::schema()
is deprecated. Use setSchema()/getSchema() instead. See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.html#deprecated-combined-get-set-methodsEmail::setTemplate()
is deprecated. Use $email->viewBuilder()->setTemplate() instead. See https://book.cakephp.org/3/en/appendices/3-7-migration-guide.html#deprecationsResponse::header()
is deprecated. UsewithHeader()
,getHeaderLine()
andgetHeaders()
instead. See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.html#request-response-deprecationsTestCase::$fixtures
is deprecated. See https://book.cakephp.org/3/en/appendices/3-7-migration-guide.html#deprecationsvendor
codeAPP
byResponse::file()
andwithFile()
is deprecated. Use absolute paths instead. See https://book.cakephp.org/3/en/appendices/3-4-migration-guide.html#request-response-deprecations~~when
andmessage
arguments so that they aremessage, when
. See https://book.cakephp.org/3/en/appendices/3-8-migration-guide.html#deprecations~~"dereuromark/cakephp-queue": "^5.4.0"
"markstory/asset_compress": "^4.0"
"cakephp/migrations": "^3.0.0"
"codekanzlei/cake-auth-actions": "^4.0.0-rc5"
"cakephp/bake": "^2.2"
Abandoned packages
There are several abandoned packages still in use even after meeting the above dependency targets. It might be better to resolve these in another PR, but I'll document them here just in case.
Remaining Deprecation Warnings
The deprecations I listed seem to be the most prolific, but as far as I can tell I got all instances of each. There are few more though.
The first one listed here in particular may be a bit troublesome. I'm not familiar with all the routing done for the application, but I assume named parameters are still in use for some routes, thus the invokation of
parseNamedParams()
. Unfortunately, it seems 4.0 and onward won't support them, so it may be necessary to write some custom middleware to handle whatever requests are still using named parameters.This is still a work in progress, but I'll see what I can do about the remaining deprecation warnings to get the application ready to use the 4.0 upgrade tool.