-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Allow apps to have their own manifest files #18584
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
Conversation
So that you save a particular part of Nextcloud (i.e. notes) Signed-off-by: Konstantin Gorodinskii <mail@konstantin.io>
kesselb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your pr 👍
Would you mind to add some insights about this change? A manifest.json per app is necessary to ...
Signed-off-by: Konstantin Gorodinskii <mail@konstantin.io>
|
@kesselb Thank you for the quick response. I wrote the reasoning in the second PR Basically I want to be able to access a part of Nextcloud directly via «Add to Home screen» feature of a mobile browser. Right now if ($image === 'manifest.json') {
try {
$appPath = $this->appManager->getAppPath($app);
if (file_exists($appPath . '/img/manifest.json')) {
return false;
}
} catch (AppPathNotFoundException $e) {}
$route = $this->urlGenerator->linkToRoute('theming.Theming.getManifest');
}The problem here is that half of the feature was already there (if the manifest exists it stays in the That's why I added those two rules. The second part is that there is never a hash added to manifest file if it exists. I fixed it in the second commit. |
|
Wrong button :) |
Signed-off-by: Konstantin Gorodinskii <mail@konstantin.io>
|
Ah. Did some testing. This approach will only work for instances with mod_rewrite enabled. It does not work with nginx. RewriteRule will tell the webserver to not forward the request for /apps/notes/img/manifest.json to nextcloud and serve it statically. That's fine but we probably need a new rule for nginx. Otherwise nextcloud must be able to serve these files (but that includes booting up everything) and serve the file. That's already there for many static assets (e.g. a generic route to serve js or css from any app). Let me ping @rullzer and @juliushaertl to ask them how to do it. The use case here is to ship a custom manifest.json for a app. URL generation seems to work already. Is this something that apps should implement theirself? Or should we tell the webservers to just serve any of these manifest.json files. That worked for me (with nginx) and will not break the theming manifest (because the url is something like |
This reverts commit d1a8af5. Signed-off-by: Konstantin Gorodinskii <mail@konstantin.io>
| $content .= "\n RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$"; | ||
| $content .= "\n RewriteCond %{REQUEST_FILENAME} !core/img/manifest.json$"; | ||
| foreach (\OC::$APPSROOTS as ['url' => $url]) { | ||
| $content .= "\n RewriteCond %{REQUEST_FILENAME} !" . trim($url, '/') . "/[\w-_]+/img/manifest.json$"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we could replace the foreach with a more generic RewriteCond. If someone is adding a new app_path he will probably not regenerate the htaccess. Such issues are hard to spot even if we document it somewhere. I'm not sure yet. Thats a obscure edge case of course 🤔
|
If we do this we should make it a generic route that is handled in some controller and then depending on what app you pass to it. Doing .htaccess magic is to error prone in my opinion. But lets revisit this when we start 19 development. |
And bootstrapping the whole nextcloud stack for serving a static file. His approach is to exclude |
|
Bump? |
|
@gko any update here? :) |
|
Superseded by #28459 |
So that you save a particular part of Nextcloud (i.e. notes)