User tests: Successful: Unsuccessful:
Have the JImage
class chain extend the Framework's Image package. For the most part this basically proxies everything in JImage
over and has JImageFilter
extend the Framework's counterpart class. The two base classes in the CMS chain will also auto-inject a logger into the instance. Deprecate most existing classes for removal at 5.0, there isn't a good way to proxy these without breaking class inheritance or if someone has custom filter objects causing them to need to rename classes.
Using the JImage
API is still possible without error.
Classes documented as deprecated in 4.x and removed at 5.0.
Status | New | ⇒ | Pending |
Category | ⇒ | External Library Libraries |
Labels |
Added:
?
?
|
Labels |
Added:
?
|
Unless we're pulling in the package on the 3.x branch it'd be more disruptive to require anyone using the API to use version conditionals for 3.x and 4.x use than to do it this way.
ok sounds fair
Labels |
Added:
?
|
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-09-24 09:56:20 |
Closed_By | ⇒ | wilsonge |
Is it deliberate that JImage itself isn't also deprecated for 5.0?
https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4#Image This has been documented as is. I think it's probably a bug that JImage isn't also deprecated in which case we need another PR and documentation update for that
The JImage constructor is automatically injecting the JLog PSR-3 bridge in for logging. Other than that, it's basically checking functionality between the CMS and Framework and ensuring they're the same.
@mbabker any reason to not deprecate the J* Calsses for 4.0 and remove it with 4.0?