-
-
Notifications
You must be signed in to change notification settings - Fork 201
Wrong path fonts #26
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
Comments
Hey @dayze! Can you post your webpack.config.js file and also the code for any relevant other files (like main.js)? |
Hi, webpack.config.js
main.js
Errors
|
Same issue here, with similar configuration. The situation seems to be that my app doesn't run on a ground-level domain, but on a alias on apache:
So webpack is trying to create the webpack.config.js:
global.scss:
Resulting global.css:
|
@heitorvrb Ah, thanks for the extra info! If you're deployed under a subdirectory, that should be reflected in your // this is your *true* public path
.setPublicPath('/mySymfonyApp/build')
// this is now needed so that your manifest.json keys are still `build/foo.js`
// i.e. you won't need to change anything in your Symfony app
config.setManifestKeyPrefix('build') You can see an example of this in the tests as well: webpack-encore/test/functional.js Line 180 in db980b4
Webpack must be aware of the true public path, because if you use "code splitting", then webpack itself will make AJAX requests for assets (so it needs to know the real path). That's why the config lives in Let me know if that helps! I'll open an issue on the docs about this. |
It worked. Thanks for the help. |
It worked too, thanks ! |
What if my web root changes depending to the environment I'm deploying to? |
@vctls Maybe you could use Encore.setPublicPath(Encore.isProduction() ? '/build' : '/my-nth-app/web/build'); |
@Lyrkan I will do that, thank you :) |
@Lyrkan what if I use artifact-based deploying and the builder do not really know where the artifact would be deployed to? Is it possible just make path relative to manifest? |
Hi @scaytrase, I guess you would need to call webpack-encore/lib/WebpackConfig.js Lines 122 to 127 in 7997206
@andyexeter had a similar issue here: #88 (comment) We could probably add an |
@Lyrkan commenting this error and passing relative path makes internal CSS files to import like
The So we really need the possibility to rewrite the paths |
@weaverryan thanks for the release 0.17.2. I tested it and it kind of works. But as you already expected, its not a solution that solves all problems. By setting But the next problem is that these relative paths become also part of the manifest.json:
That now collides when using the
and
results in
We could now disable the All in all your fix might solve some problems, but I guess it doesn't help with the usecase of generating assets in a way that they work both on root level and in a subdirectory in combination with SF4 and Twig. But I am new to encore and webpack, so I might miss something, any help would be great. |
I’m going to re-open so we can process the new info |
@kevinpapst couldn't you do simply
or am I missing something? |
@stoccc before the patch it was required that public path starts with |
@stoccc No, the public path is not only used for building the manifest.json, it is used to reference assets like font urls within scss files. So a generated css file, lets say |
I had same problem. and I solve like this I have
to
Actually, I'm not sure. Is it secure way to use? |
@weaverryan it seems that 0.17.2 has not yet been published to npmjs https://www.npmjs.com/package/@symfony/webpack-encore |
@stoccc and everyone who wants to test. you can change your
|
I am in this scenario:
I have deleted these two lines of code in version 0.17.2 (they add a traling slash if it is not present), so that I can have a public path defined as With this configuration in webpack.config.js
all works correctly:
I am wondering: is this solution acceptable or are there some other consequences/scenarios which I can't figure out (I'm new to encore/webpack and nodejs..)? If it is acceptable, we could test if |
I tried many combinations, but missed that the slash is automatically added on an empty string. I can confirm that your solution works @stoccc. Thanks, good spotting! |
@weaverryan I can confirm that @stoccc way worked to mee to with latest version installed from github (like @kevinpapst referenced). Commenting out these two lines makes base directory changing work without touching any code or configs |
Awesome! Then we should create a PR! I need to do some git blame to make sure I remember why that trailing slash is so important usually. However, based on why I’ve heard, we may be able to skip that trailing slash of the publicPath argument does not have the starting slash. Basically, you’d opt in to absolute paths or relative. So yea - can someone create a PR? We have a great test suite in functional.js - it would be pretty easy to setup a seriously solid test to make sure the edge cases all work. |
yes I vote for @stoccc +1 |
Provided a functional test. See symfony#26 (comment)
Any news on this issue? |
I'm sorry but in these weeks I can't work on it.
2018-03-08 10:20 GMT+01:00 Patrick <notifications@github.com>:
… Any news on this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AXqHI2Azkt686RK2wO0EgJGklO7e67cUks5tcPfvgaJpZM4N8PKQ>
.
|
@stoccc solution does not seem to work when using dynamic import (promise). |
there are multiple cases not working:
In both cases, webpack needs to know the path to put them in the DOM, and a relative path here would be relative to the document (so being on |
Two cents: i.e. My Current Issue: Currently using Symfony 4.1 with
My Solution
Symfony Framework issue: Using PublicPath = '../build' and json_manifest_path, this is sample of what occurred
Web page =
Settings: Not sure if I should create issue in Framework for this until Encore issues are resoled (if possible). Thanks, Dave |
Hey Dave! There may be a misunderstanding about the public path setting. Or maybe the docs are indeed over simplifying things :). If your app1 will ultimately be accessible as example.com/app1, then your public path should be /app1. Webpack / Encore doesn’t care that your app is in s subdirectory or even know this (unlike Symfony, which can detect it). The publicPath is much simpler: it’s used as the prefix to your assets when they are built. If your app will ultimately reside under /app1, then that’s your publicPath (plus any /build directory where you’re putting things). The warning is meant to be annoying - bad/strange things happen (at least currently) when you try to make this path relative. So, that would be my recommendation: make your publicPath /app1/build because that is the final public path to our assets - it doesn’t matter what the underlying file structure looks like :). |
@weaverryan sorry I did not see your reply until today. I forgot to add myself to watch. Thanks for feedback. Your recommendation to define publicPath, does work when using Apache web server, however
Here is example showing 404 error when using server:run:
Here are project settings I tested by changing project
Any ideas or suggestion how to resolve this would be greatly appreciated. Thanks, Dave |
@dspiegel relative public path can work on the Symfony side, because it can auto-detect the path needed to access the app web root from the server web root. But webpack itself needs to be able to load more files from some files it generates, and it cannot auto-detect the webserver configuration at build time. And the 404 you faced when using |
I am just desperated that SF team opted for a JavaScript solution to handle the assets. Nothing works no more with this technology. And there is no way to maintain it without absorbing a whole lot knowledge about JavaScript. I just hate this "language". When it's not the sass-loader that falls down, you discover that it just can't handle multiple environments. I think I will end with totally uninstalling webpack and find a working PHP solution, that can be configured, fixed, and adapted if necessary to anyone's needs. Frustrated. Why don't you use a stable language, something defined, something that runs the same on any environment. Something that works like any other language. Or maybe it's time to stop working with SF, but it is so sad ... |
@dmeziere you are still free to build your assets the way you want, and reference them with the Modern tooling regarding building frontend code is all written in JS. And we decided to recommend webpack (with this wrapper around its config to simplify it for the use cases we see). But it is not mandatory to use it with Symfony at all. And regarding using a pure PHP solution, there is no PHP-based tooling implementing a module bundler for JS (JS developers build their tooling in the language they know: JS). And the Symfony core team has no interest into porting Webpack and its whole ecosystem to PHP (that would make no sense, and would require many full-time developers to catch up with the whole webpack community). |
So, I finally found the problem. It was an impact on fos_js_routing. But the frustration of loosing days on this point didn't help me to see things clearly. Finally the solution provided by @Lyrkan was the key as I also use aliases on my dev server, but not on my production server. But if you, falling on this ticket, are using fos_js_routing; be aware that the generated js/json file is not called anymore. It is integrated by webpack encore to the main JS file (what makes sense, after all). So you must make it "prod friendly" before calling yarn encore production. And you no longer need to dump the routes in your deployment script, this will be useless. Finally, I don't like the fact that I must compile and commit my production assets to my repo before a deployment, but it is way better than being forced to install node on the production server, downloading all the node_modules, etc. |
@dmeziere Building the assets before a deployment is a good thing, but I'm not sure why you'd have to commit these files. By the way, if you have more than two public paths to manage you can do something like this: Encore.setPublicPath(process.env.ENCORE_PUBLIC_PATH || '/build'); Then simply set the |
I use sub directories for sites while in dev and it was a bit of a pain setting a publicPath. Especially when co-workers had different sub directory structures. I wrote some code to automatically determine the public directory across all projects within the webpack config. webpack.config.js
You will need to install dotenv from yarn for this to work. In the above code we are just giving it an array of potential web root directories to look for. This is a list that a few different co-workers are using. As soon as the loop find a value that matches the __dirname variable, it will take that value and append /public/build to the value. e.g. if your build files are located in /usr/local/var/www/htdocs/clientXYZ/project123/public/build it will make the public path /clientXYZ/project123/public/build We also have a .encore.env.dist where you can set a value for ENCORE_PUBLIC_PATH |
Some of us don't use CI/CD builds and must commit these files. |
@toklok Even without CI/CD I wouldn't recommend commiting them. Building them locally before a deployment, or even directly on the server (which is not really a good thing either) are probably better solutions. |
My temporary solution:
if (Encore.isProduction()) {
module.exports.plugins[2].options.publicPath = 'bundles/w3desadmin/build/' // [2] is WebpackManifestPlugin position
} Now after yarn run build I have css with relative paths, and asset() function works fine. Unfortunately entrypoints.json have wrong paths, I cannot override it in similar way because AssetsWebpackPlugin calls webpackConfig.getRealPublicPath() directly. |
Thank you for this issue. |
When I include semantic or bootstrap in my main.js I end up with a 404 not found error for the fonts
Apparently, the output path of fonts go to the root of my web server like this
http://localhost/build/fonts/icons.woff2
The text was updated successfully, but these errors were encountered: