I'm trying to install Joomla 3.x with MS SERVER. I try to press INSTALL button on last step and it just redirects me to the same place and doesn't actually install anything.
https://img.exs.lv/e/z/ezeliitis/Untitled.png
What could cause this? :/
Have you ensured that all the prerequisites were installed on the application server? This is an old post - but check this: https://docs.joomla.org/Configuring_sqlserver - it should lead you to the right solution.
This can happen if you have max_execution_time=30 in your php.ini file. This means a script can run a max for 30 s. Sometimes database entry takes time gretaer then 30s. So the installation halts. What you need to do is change it to a higher value in your php.ini file. I kept it max_execution_time=1000.
Related
I originally posted this to the Continuum github but didn't get a response, so thought I'd try stackoverview.
I have been trying to create a Python 3.4 environment with the latest installer, which I managed to get through the early part fine. It downloads the first few packages but hangs at 99% then subsequently times out when it gets to this package.
https://repo.continuum.io/pkgs/free/win-64/qt-5.6.2-vc14_3.tar.bz2
I can download it manually in Chrome but it has a similar behaviour - getting stuck at 55.2/55.3mb and stays there for a while before completing. I'm behind a proxy but I do have the correct proxy settings in .condarc. Is there a way to change the timeout limit when I'm downloading it through conda?
Cheers
I had the same issue. In conda < 4.3.0, the timeout was hardcoded to 60 seconds. In Windows, I'm guessing, that's not enough for huge package with a lot of binary files like qt since most likely the virus scanner kicks in to check the files. You can hack your ~userid\AppData\Local\Continuum\Anaconda3\lib\site-packages\conda\fetch.py and change the hard-coded constant yourself, eg. from 60 to 300.
With newer version (I'm not sure when this was added, but I see this in my conda 4.3.22), running conda config --show gave: remote_read_timeout_secs: 60.0. So I believe you can modify it by adding it to your ~userid\.condarc file.
I want to uninstall xampp and reinstall with the latest version. I've recently upgraded from Win7 to Win10 which I think is causing many of my problems.
I have saved all my files and folders, so that I can insert into the new version of xampp.
After I click "uninstall" I get this message "The uninstall.dat file cannot be found and is required to uninstall the application, aborting".
There is an uninstall.dat file in xampp and it is an Adobe file. I've tried changing it to Notepad and Editpad but still get the cannot be found message. And I've tried many times without success.
Can somebody tell me how to overcome this problem?
Maybe I need to uninstall by piecemeal but I don't know how to do that.
18/02/16 - Update.
The only solution I can think of is to move the xampp folder to the recycle bin.
In that event, how could I see if any of the programs are still running, and if they are, how to delete them?
I need to answer my own question, in case another person has the same problem. I deleted the xampp folder to the recycle bin, downloaded Version 7.0.4, installed and uninstalled, then installed once more. Everything appears to be working now. This may have been a fault with Version 7.0.2 which is what I had these problems with.
Actually I used XAMPP nearly four years ago during my college project, now not using it anymore, so I though to uninstall it but unfortunately got this same issue, just did a simple thing to resolve the issue, I had that setup from which I installed it, so using that I reinstalled it and then did the un-installation and it worked for me.
Copy paste required file into xampp folder and uninstall xampp as regular procedure via control panel.
Trying to upgrade from 1.3.2.4 to 1.4.
I set up MAMP and created an empty database into which I imported the exported database from the online site (done via phpMyAdmin from the cpanel of the site).
Copied 1.4 files into htdocs and got the installation screens.
After entering the details for the imported database, the process crashed and I got a blank screen.
I've tried changing the base url string in the core_config_data table and redone the whole process but to no avail.
I've also tried setting up a clean install of 1.4 and using the database repair tool to perhaps bring the old database up to spec but that didn't work either.
I basically need a proper way to upgrade this site to the latest version (1.8.1) but I thought I'd start with 1.4 first. At the very least I'd like to have a database that can work in a fresh 1.8.1 install.
You need to find out what the error is before you can begin to fix it. The blank screen means that you are not getting those errors. It may be a simple timeout. What is in your php.ini for error reporting and timeouts?
With your 'MAMP' you can try a vanilla Magento install and see if that works. Try 1.3.2 with the demo data in the db first. Then point it at your copy of the live db and see if it still works or if it dies due to some module dependencies.
That should get you to the starting point. As for where you are now, check the apache log files to see if the error - maybe just a timeout - is in there.
On upgrade Magento does loads of stuff, as per the upgrade scripts with each module. This is database intensive stuff and by doing a dry run on a vanilla database you can see what you are up against.
Hope that helps.
I am trying to install latest version of Prestashop and it fails when installing modules.
I get no error description, just that modules could not be installed and that I can try again.
I am answering my own question because maybe some day someone finds this useful.
I did some debugging to see where did the installation fail, and it was giving an error complaining about calling the install() method ona non-object variable.
I changed some php code in the modules install script, and I saw it was failing in the statnewsletter module.
I did not knew why was that, so what I did is go to the FTP and check the files of that module, and surprise, all files had 0 bytes size!
So, the porblem was that my FTP client (Filezilla) did not upload the files correctly.
I've uploaded all the prestashop files again overriding all files and then the installation worked fine.
What I've found on the web is that Filezilla can leave the file with 0 size if the server doesn't respond on the 20seconds timeout limit. And that the timeout limit can be increased in Options to avoid this happening.
Hope helps someone!
I've got an MSI based install that I've wrapped in an EXE file as per my installation packaging software (which is Wise Package Studio 7.0 SP2).
I've made many changes to the install, and every time I've tested them, they've worked just fine... up until now.
I changed some text on a dialog box for when the installation finishes and now it seems that no matter how/where I run the installation from, it won't take my "new" version. It continues to "think" it's already installed and even shows an older iteration of my dialog text at then end of the removal/repair/modify.
It's almost like it's cached that MSI/EXE somewhere and instead of running the one I've recompiled (and fixed the message/made changes) it continues to run the "old" one from somewhere.
Any idea what to check for/what could be going on here? Is there windows folder I need to go check? I'm on XP SP2.
Try running on a different machine, this will definitely rule out any local caching.
Check that the changes you have made are actually in the MSI. (use Orca to do this.)
Okay, so I tried this using an XP VM and taking a snapshot before installing. Looks like somehow the previous install was corrupt and was somehow caching itself on the original test computer I was working with.
By going to a clean and fresh PC, my changes were there and the script worked as expected. Now, I don't know what happened to cause the installation to cache like that somewhere on the PC, but at least I found a resolution.
I'll update this question with the location of the cached files if I can track them down...
To remove any cached Windows Installer information, you can use MSIZAP. My guess is that you haven't changed the package code so windows sees it as the same version of the installer (I'm not sure about WISE, but InstallShield is usually configured to automatically change the package code each time you rebuild.)
As far as the location of the cached files, this is configurable so have a hunt around in WISE and you should find it.