After migration to 2.2.1, all public assets, including javascripts and css return 404 in PROD mode - playframework-2.2

I migrated to 2.2.1 one week ago and I am encountring some serious issues, my project worked fine in 2.1.5.
Since earliest play2 versions, I have been using the following procedure to access my public assets (copy pasted from the official doc):
-> routes file :
GET /assets/*file controllers.Assets.at(path="/public", file)
in template file:
<link href="#{routes.Assets.at("stylesheets/bootstrap.css")}" rel="stylesheet">
without any problem.
However, now that I upgraded to 2.2.1, it's only working in DEV mode (play debug / run), in PROD, all my assets URLs return 404 errors.
I tought it was a packaging problem, checked the main jar file, I could see the public folder and the various *.js and *css files so they seem to be properly included. Also the generated URLs look clean :
http://localhost:9000/assets/stylesheets/bootstrap.css
I use a single module layout and develop on windows 7. I tried deploying on a linux debian 6 but had exactly the same issue.
I would appreciate any help, it seems that I am not the only one having this problem but no information about a possible fix yet... Reverting to 2.1.5 would be a difficult task because 2.2 introduced some serious incompatibilities in the API and required many code changes.

You should have /assets/*file instead of /assets*file in your routes file but I doubt this will resolve your problem.
If you have other specific routes for some assets, make sure the general GET /assets/*file is the last one in your routes file.

I finally found the cause of the problem by removing all dependencies from my project one by one.
One of the plugin I am using (Japid) was compiled with an earlier version of play 2.2.x and was incompatible with 2.2.1, that caused problems with assets routing.
Fortunately, japid author has been very responsive and fixed the issue. (see release 0.9.14.1)

Related

Processing 3 IDE is half cyrillic

Recently I started to find interest in Processing and decided to download the offical Processing 3 IDE from https://processing.org/download/?processing. But half of the IDE is in cyrillic symbols.
Screenshot of the IDE
I already tried to change the configuration language etc. Also I downloaded the IDE to my workplace notebook and on the notebook the IDE was complete in normal english.
Now I dont know how to fix this problem, because there are no informations about a problem like this with the Processing 3 IDE.
A few things to try - you may have already.
I know you said you tried changing the config language, but I'm not sure if you changed the "language.txt" file in the directory "C:\Users\your_username\AppData\Roaming\Processing". Ensure it only contains one line - "en".
Fresh install of Processing (delete the folder you extracted to and the Processing folder in the directory mentioned above, and the sketchbook folder, usually in your documents).
UPDATE:
This is a solution which has worked for others experiencing this exact issue:
Download Processing 3.1.1 - https://github.com/processing/processing/releases/tag/processing-0250-3.1.1
Make sure Processing is not already running
Rename the java folder in the processing-3.2.3 directory to something else, eg. java_broken
Copy the java folder from 3.1.1 to the 3.2.3 directory
Try running the 3.2.3 version of processing.exe

Sylius Stylesheet Not Reloading

So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!

Joomla 3.0: modul.js: $extend is not defined

I upgraded from 1.5.x to 3.0.x. During migration the new pages was setup in a separate directory, so the old one could be used without any downtime. After installing all required modules, templates and reorg of some structures I deleted the old page and moved all file from the subdirectory to the root directory. (In addition I change the configuration, so the subdirectory is no longer referenced.) Every thing went well and the user front end seems to be OK. Within the administration pages I have an major issue:
Any page that requires a modal panel (e.g. defining Images for Banners, defining menu items) throws an Javascript error and the page cannot be used:
Uncaught ReferenceError: $extend is not defined modal.js:368
(anonymous function)
Do you have any hint how this issue can be solved?
Thanks.
Karsten
Try re-uploading all files in the directory:
/media/system/js/
If the error persists or other error occur, consider uploading the Joomla core files again.
Please not that file by file FTP uploads are sensible to error. It's generally more safe to upload a zip and to unzip everything on the server (not to mention it's faster).
For those that aren't fixed by just re-uploading /media/system/js, this error can crop up for people who do an extremely far upgrade (like 1.5.x to 3.0.x mentioned by the poster) because "$extend" has been deprecated (and eventually removed) in mootools.
This means that your old extensions may be trying to use code that no longer exists in mootools. If you can find updates for the extension causing the issue, that's probably enough of a fix. If you can't, then it's usually easy enough to fix on your own...
The short fix for this bug is to change $extend to Object.append
Here is some more info about the upgrading mootools in general, which may help with other issues.
https://github.com/mootools/mootools-core/wiki/Upgrade-from-1.2-to-1.3-or-1.4

Spine.js and Hem: Getting started

I successfully created a Spine app as explained on Spine's Getting started page.
However, Hem doesn't automatically take my changes into account; I have to build manually.
I have the same problem when I follow the contact screencast, but this time Hem does not build at all:
art-mac:spine.contacts art$ hem build
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Cannot find module: spine/lib/tmpl. Have you run `npm install .` ?
I did run 'npm install .'
Surprisingly, when I reinstall spine.contact (in another folder), the contacts I created in the previous contact application appear in the new application...
"Disable cash" in my Chrome development settings in is checked.
I was having the same problem when I first upgraded hem to version 0.1.9. One thing to check for is if there are compiled application.js and application.css files in the public folder of your application. It seems like when these files already exist hem server would serve those files instead of recompiling from the sources. Once those files are removed hem server would then use the source files to dynamically create the application files.
But this behavior did seem a bit different from older versions of hem. I was able to make a couple of changes to the hem server so that it seem to work as before, in that the hem server would always compile from the source files regardless if the application files already existed. I posted the code changes on a similar issue at the hem github repository https://github.com/maccman/hem/issues/46#issuecomment-6550866, but I'm not sure if its a hem issue or if something changed with the strata web server library that hem uses.
The latest Hem in npm (0.2.7) should solve this issue.
The strata server was having issues serving files dynamically if they already existed.
Hem 0.1.9 (the latest version) is not automatically detecting changes to my spine app when running "hem server"(although "hem watch" seems to be working correctly). I was able to get it working by uninstalling 0.1.9 (npm uninstall -g hem) and installing 0.1.8 instead (npm install -g hem#0.1.8).
Regarding your other issue, spine/lib/tmpl is no longer included in the latest version of spine, so if you want to use the screencast you'll need to install whatever version of spine he is using.

How to install play! framework modules?

I'm trying to install this pagination module for my Play! application, but can't get it to work. I've extracted the zip file inside /play/modules/paginate-head/ and I an example here on SO, to change my dependencies.yml file into:
# Application dependencies
require:
- play
- pagination -> paginate-head
repositories:
- My modules:
type: local
artifact: ${application.path}/../[module]
contains:
- paginate-head
But I still don't think the module is being loaded. I'm assuming it's documentation should appear on http://localhost:9000/#documentation/home or are there other ways to see if a module was loaded? It's not telling me anything in the console neither.
Any ideas how to get this installed?
You don't need to extract a zip file, just running the command
play install paginate-head
should work fine. But unzipping will also work. You also don't need that "repositories" section in your dependencies.yml file. Play! knows where to find modules.
The real issue is that your require should look like this:
require:
- play
- play -> paginate head
Notice play to the left of the '->' which signifies that it's a module. Also no dash between 'paginate' and 'head'. That's because 'paginate' is the module name and 'head' is the version and these should be separated by a space.
Also, for modules that are hosted in the main Play! modules repo, you don't even have to install them. You can just add the require above and start Play! and it will install it automatically. Though it will install under the applications modules directory, not the play modules directory.
Hope that helps!