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
Related
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!
With SocialEngine's RESPONSIVE FileManager-based file uploader, itself a plugin component for the rich text editor, we are having a problem whereby when a user clicks "JAVA Upload (big size files)" the uploader frame loads a 404 error.
In the error log, the following line is the only indication I have for this problem:
/filemanager/dialog.php?type=4&descending=false&crossdomain=1&lang=en&akey=key
So it's not immediately obvious what framework or plugin Responsive FileManager expects to encounter which it can't actually find, or for that matter, where it's looking to find it. (I have RTFM but there is nothing about configuring the Java uploader in the manual. I have also tried reading the dialog.php source code but I couldn't find anything particularly useful when I did so.)
It may perhaps be looking for the file wjhk.jupload.jar in the
filemanager/uploader/
directory. But I'm not sure why it can't find that file, or why it gets an error when it attempts to do so.
Surely I am not the only person to have this problem?
SocialEngine doesn't come with a Java uploader at all, and its largely advised against using java for file uploading on the web.
It sounds like work of a 3rd party plugin (that might be misconfigured?). Check all your plugin files and make sure they were all uploaded to your server. Its also possible that your host disallows .jar files as they tend to be vectors for abuse. So it is worth contacting them.
Finally, contact the original developer of the plugin with your issue.
I am having the most frustrating issue with VQmod. I moved my OpenCart store from a Godaddy VPS to Rackspace's Cloud Sites. The move went fine and everything works properly except the VQmod's on the admin panel. None of them load. No errors in the log files, no admin cache files in the cache dir, no php errors.
Things I have tried:
Cleared all cache Changed admin folder to 755
reinstalled VQmod tried both manually and using the installer with fresh index.php files
Removed all XML files and tried to load only one at a time
Cursed loudly at my computer repeatedly.
Please Help! OC version 1.5.6 VQmod 2.5.1
For those that want the solution to this, the issue was that the config.php files were both using relative paths instead of the full paths for OpenCart's various directories. They should always be full paths, or resolved with realpath() in the config.php files themselves
My case was a bit different. I checked the permissions, paths, all the regular stuff that comes to mind first. I even walked step by step through the manual installation guide.
The Opencart copy in question is shared across several environments using git. Long story short, the mods.cache and checked.cache were not added to .gitignore right away, and when I finally did that, I emptied both of them just to make sure Opencart will write new content based on my current environment. Turns out, since mods.cache was empty, Opencart believed there are no mods available.
Solution: delete both vqmod/mods.cache and vqmod/checked.cache.
Update: here are some similar issues:
https://github.com/vqmod/vqmod/issues/32
https://github.com/vqmod/vqmod/issues/3
The vqmod/vqmod/wiki/Troubleshooting guide, as of now, does not make it obvious the files should've been deleted, neither does the vqmod/vqmod/wiki/Installing-vQmod-on-OpenCart, and there doesn't seem to be any way to contirbute. vQmod fails silently, without producing any notifications, warnings, or simply detecting the issue and rebuilding the cache files. I've spent few hours trying to figure out what's wrong.
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)
My application runs as a Windows service. During normal execution, some data files are generated in a "data" directory that I create with my WIX install. During an upgrade, I would like to move/migrate those files to the same data dir in the upgraded installation. However, I am running into issues. I am using the "MajorUpgrade" tag as follows:
I tried scheduling later in the process(afterInstallFinalize), but that runs into issues with the service having locks on files during the upgrade. I have combed Stack Overflow and google, and it seems that no one else is describing my scenario. Others have default *.ini files, that the user can potentially edit. However, in my case, it should always be safe to migrate the files, as there are no defaults. They are simply data files that need to be migrated.
I thought I could possibly do this via a custom action, but was not sure how to do it.
Any suggestions would be very much appreciated.
Edit: Apparently using "afterInstallFinalize" works fine for me, i.e. data files are migrated, as long as the user does not change the path during upgrade. If I change the path during upgrade, I get warnings about files being locked, and asking to stop the app using the files. However, it ends up not migrating the files in that case.
Ultimately, I solved my own issue by simply overriding the default dialog behavior, and changing the flow such that on upgrade, I skip over the "InstallDirDlg".