Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typo3/cms-composer-installers:^4 compatibility will need some work #271

Closed
jonaseberle opened this issue Mar 31, 2022 · 4 comments · May be fixed by #323
Closed

typo3/cms-composer-installers:^4 compatibility will need some work #271

jonaseberle opened this issue Mar 31, 2022 · 4 comments · May be fixed by #323

Comments

@jonaseberle
Copy link
Member

jonaseberle commented Mar 31, 2022

The new generation of typo3/cms-composer-installers uses URLs to EXT:.../Resources/Public/... that must be generated via the FileResource API.

This will need changes to our test extensions and documentation.
We will probably have to develop a solution how our JavaScript can dynamically include JavaScript from e.g. the site package.

Or just tell users they shall dump their loadable assets to some folder in ./public now. But this won't be a nice solution if people want to dynamically load assets from a 3rd party extension.

Relates: TYPO3/CmsComposerInstallers#131

jonaseberle added a commit that referenced this issue Apr 6, 2022
With v4, the extension part of public URLs of assets is scrambled at
`composer install` time. Proper paths can be build at runtime with the
TYPO3 FileResource APIs.

We will have to supply ai new way to include assets from other extensions
in our HTML `inject ( )` blocks.

This currently breaks our tests (and local development instances) as
well as live sites including local assets.

This will need some more thought.
Ideas are welcome.

Relates: #271
@jonaseberle jonaseberle added this to the Next major version: 3.x.x milestone Apr 12, 2022
@jonaseberle
Copy link
Member Author

@jonaseberle
Copy link
Member Author

jonaseberle commented Jan 9, 2023

We could...

  1. make inject a string / stdWrap (probably with recommendation to use {path : EXT:...})

    • Requires users to update their cookieman configuration for injected local URLs.
    • Does not solve the greater problem of referencing arbitrary assets from JS or from an external system.
    • Could benefit from cache-busting param feature (probably only v12+)
  2. have a middleware that keeps /typo3conf/ext/.../Resources/Public/... working by either readfile()ing or forwarding (307) to the final location. For performance it could transparently add symlinks on the fly if the file system is writable (to be used for consecutive requests).

    • Benefits all use cases that want to continue using known local URLs.
    • For sending via PHP: Setting headers adds an unnecessary layer and potential source of problems. Doing a local request for passing through web server's headers could be a performance problem or fail in some environments.
    • For forwarding: Needs validation if it works reliably with all types of assets in all browsers (should in theory).
  3. have a composer plugin that manages symlinks for installed/uninstalled typo3-cms-extension packages.

@jonaseberle
Copy link
Member Author

Relates: a-r-m-i-n/min#12

@jonaseberle jonaseberle mentioned this issue Nov 3, 2023
9 tasks
@jonaseberle
Copy link
Member Author

jonaseberle commented Nov 9, 2023

By using 1. now we are trying to stay close to "how it is supposed to work".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant