I tried to go to the download location and download the binaries (or even the src) https://ignite.apache.org/download.html#binaries
I can see the link pointing to the following:
https://ignite.apache.org/[preferred]/[distdir]/1.6.0/apache-ignite-fabric-1.6.0-bin.zip
but I get 404 response
poking around the directory structure, I managed to find the real link :
https://www.apache.org/dist/ignite/1.6.0/apache-ignite-1.6.0-src.zip
still I suspect the official download links should be fixed.
In case this happens, choose a mirror using the 'Selected mirror' dropdown. The page should choose the closest mirror automatically and it works in most cases, but it's a bit buggy and sometimes you have to do this manually.
Related
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 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
So, I'm running an apache server on linux. Sometimes, Firefox decides to not load the new version of a file after I edited it. For example, right now I have a .js file wich is loaded dynamicly. It had a bug, wich I corrected (I checked with Chromium), but when the file is loaded in Firefox, it still has the bug! When looking at the response header of the ajax request, I see the code of the file BEFORE it was changed. But that code doesn't exist anymore... I had this happen with CSS files too.
When I rename the file to something else, it loads the right stuff, but as soon as I rename it to the old name, it starts loading an old version of the file again!
I restarted apache2, but that didn't change anything.
I checked for file permissions too, no problem there as far as I could tell (I changed all files' permissions to rwxrwxrwx to be sure).
When accessing with an other browser, it works fine!
In previous cases, the next day or so, the problem would have vanished, but I can't always just stop for a day in what I'm doing...
This is caused by browser cache,
you can consider to use url with version parameter,
like http://yourdomain.com/js/some.js?v=$version,
and update the $version whenever you update a css/js
I am working on a small toy project who is getting more and more releases. Until now, the documentation was just a set of pages in the wordpress blog I setup for the project. However, as time passes, new releases are out and I should update the online documentation to match the most recent release.
Unfortunately, if I do so, the docs for the previous releases will "disappear" as my doc pages are updated to the most recent version, therefore I decided to include the documentation in the release package and to keep the most recent documentation available online as a web page as well.
A trivial idea would be to wget the current docs from the wordpress pages, save them into the svn and therefore into the release package, repeating the procedure at every new release. Unfortunately, the HTML I get must be hacked by hand to fix the links (or I should hack wordpress to use BASE so that the HTML code is easily relocatable, something I don't want to do).
How should I handle the requirements of having at the same time:
user-browsable documentation for the proper version included in the downloadable package
most recent documentation available online (and properly styled with my web theme)
keep synchronized between the svn and the actual online contents (in wordpress, or something else that fits nicely with my wordpress setup)
easy to use
Thanks
Edit: started a bounty to see if I can lure more answers. I think this is a quite important issue, and it would be nice to have multiple hints and opinions for future readers.
I would check your pages into SVN, and then have your webserver update from its local SVN working copy when you're ready to release. Put everything into SVN--wordpress, CSS, HTML, etc.
WGet can convert all the links in the document for you. See the convert-links option:
http://www.gnu.org/software/wget/manual/html_node/Advanced-Usage.html
Using this in conjuction with the other methods could yield a solution.
I think there are two problems to be solved here
how and where to keep the documentation aligned with the code
where to publish the documentation
For 1 i think it's best to:
keep the documentation in a repository (SVN or git or whatever you already use for the code) as a set of files, instead of in a db as it is easier to keep a history of changes (an possibly to stay in par with the code releases
use an approach where the documentation is generated from a set of source files (you'd keep the sources in the repository) from which the html files for the distribution package or for publishing on the web are generated. The two could possibly differ, as on the web you'd need to keep some version information (in the URL) that you don't need when packaging a single release.
To do "2" there are several tools that may generate a static site. One of them is Jekyll it's in ruby and looks quite complete and customizable.
Assuming that you use a tool like jekyll and keep the files and source in SVN you might setup your repo in this way:
repo/
tags/
rel1.0/
source/
documentation/
rel2.0/
source/
documentation/
rel3.0/
source/
documentation/
trunk/
source/
documentation/
That is:
You keep the current documentation beside the source in the trunk
When you do a release you create a tag for the release
you configure your documentation generator to generate documentation for each of the repo/tags//documentation directory such that the documentation for each release is put in documentation_site/ directory
So to publish the documentation (point 2 above):
you copy on the server the contents of the documentation_site directory, putting it in the same base dir of your wordpress install or linking from that, such that each release doc can be accessed as: http://yoursite/project/docs/relXX/
you create a link to the current release documentation such that it can always be reached as http://yoursite/project/docs/current
The trick here is to publish the documentation always under a proper release identifier (in the URL, on the filesystem) and use a link (or a redirect) to make sure that the "current documentation" on the web server points to the current release.
I have seen some programs use help & manual. But I am a Mac user and I have no experience with it to know if it's any good. I'm looking for a solution myself for Mac.
For my own projects, if that were a need, I would create a sub-dir for the documentation, and have all the files refer from the known-base of there relatively. For example,
index.html -- refers to images/example.jpg
README
-- subdirs....
images/example.jpg
section/index.html -- links back to '../index.html',
-- refers to ../images/example.jpg
If the docs are included in the SVN/tarball download, then they are readable as-is. If they are generated from some original files, they would be pre-generated for a downloadable version.
Archive versions of the documentation can be unpacked/generated and placed into named directorys (eg docs/v1.05/)
Its a simple PHP script that can be written to get a list the subdirs of the /docs/ directory from the local disk and display a list, and highlighting the most recent, for example.