I can't log into Magento,
I installed GTSPEED extension. I logged out from admin and now I can't log in, but it doesn't show any kind of error.
How could I solve it? My site is running and I need to operate. Thank You!
just check weather you comment this line or not
app\code\core\Mage\Core\Model\Session\Abstract\Varien.php
just comment this line if you not comment it find following line and comment it
call_user_func_array('session_set_cookie_params', $cookieParams);
and then check weather it's work or not
Before installing modules like this, it's imperative that you shut off caching (and if you use it, the compiler) and only reenable after the module has properly installed itself.
After-the-fact recovery says that you will need to clear the cache (manually by deleting all the mage--? folders in var/cache) so all the old Magento code gets flushed so Magento can properly re-read all the config files and properly integrate the module into its running system and then remove all active sessions by deleting files in var/session. Once this is done, you will have to log into the admin panel and back out about two or three times so it starts loading the menus and config setups.
Related
I don't know exactly why my drupal 7 website became suddenly slow last week, after few days in production.
With xhprof, i see that at each page load,the system_list_reset() function triggers a call to cache_clear_all() function.
I deactivated all cache features.
I've read that it may due to missing files in modules and/or themes, but I didn't find missing files (except a wrong issue in 'missing module message fixer' module that indicates a missing module in view_export sub-module of view module).
I manually searched them , I didn't find where drupal can list these missing files.
Or maybe it's due to another problem.
Regards,
Open page inspector of your browser and in network tab check what files have unusually long loading time. It maybe be that some external service is causing this. Also it can be that your site is hacked...
Check most banal reason, the storage space - maybe disc of your server is full?
Check if file paths drupal is using are writable. Go to Configuration -> Median -> File system and just click Save. If some path is not writable it will get red outline.
Go to Reports -> Recent log message and check if some issue is maybe logged there. Also check for web server/php logs.
Try updating modules and drupal core - maybe some bug caused that and it's hopefully fixed in module update.
If not, try disabling modules one by one and see will that still happen. If you don't find problematic module try the same method with your theme. Would be good not to try this in production development and/or make backup before doing this.
thanks a lot,
by disabling module one by one, and by "datamining" in drupal DB, i've found that ADVAGG module was guilty.
The clean was difficult, because some entires remains in some tables of Drupal DB afther the module removing, but I hope it Ok.
BEWARE OF ADVAGG MODULE !
Funny :-/ with 'top', I've found a mining soft in /var/tmp/
systemd-private-a5422b1e6694466bbb0b63203573cad1-apache2.service-jMBN4U : nullcrew (from https://github.com/xmrig/xmrig)
I will investigate how it could land on my webserver
Best regards,
For some reason my Magento 1.6.2 site has gone into maintenance mode twice in the past 12 days, yet I haven't installed or updated any extensions (as far as I'm aware) during that time. It's pretty frustrating, since I don't even realize my site is down until I hear it from a potential customer. I can easily fix the problem by deleting the maintenance.flag that gets created in my root directory, but I want to know how to stop this from occurring. I'd hate for my Website to go down while I'm sleeping or over the weekend, and lose out on hours-days of potential revenue.
Has anyone else encountered this issue of phantom maintenance.flags being created? Is it possible one of my previously installed extensions is automatically updating and causing a problem? Is there any way to disable my site going in to maintenance mode without my consent? Any help is appreciated!
The problem might be error in one of your page rendering, like your one of file might contain error and on execution of that particular page(on request by customer) it gets error and goes into maintenance mode.
If you check index.php file, you’ll notice one interesting thingy, it checks for existence of “maintenance.flag” file in store root, if it’s found your store is put into maintenance mode. Service Temporarily Unavailable page is displayed with Please try again later message.
So I have been given the task of upgrading one of our companies' old websites that is based on 1.5 to something newer (because a second site of ours on the same version just got hacked).
I know some php and some other web stuff, but I'd never used Joomla.
I have setup a lamp server on a local VM (ubuntu) for me to test it all out on, then upload the upgraded version as is suggested. My problem now is that I know the permissions are not correct because when I tried installing Akeeba Backup, it kept throwing errors such as "could not copy to /var/www/components and /var/www/administrator etc. I went in and chmod'd those 2 (and then the rest of www because of more errors) to 757 (from 755 for the most part) - which i know at that point might as well be 777. Then when I've tried to use Kickstart to restore from the JPA file I have, it just right away throws an error "could not create j_backup/ folder".
I know this slackening of all permissions on the root folder is wrong, but it was the only way to get it to 'work', which it's not even now, so my question is what did I do wrong in the setup and how do i fix it? I'm not great with Linux, but I'm thinking I have to make PHP owner of www? is that right? or terrible practice?
The other issue I see now is that I just installed the latest php and everything and I see Akeepa says not to use php 5.4... not sure how much of a problem that's going to be....
Some direction would be great because I'm more than a little lost.
Thanks!
This is certainly a headache. Most often, as you stated, the issue is the ownership of the files on your server. Files uploaded via FTP will be owned by your FTP user and may not be editable by the Apache/PHP user. Similarly, files created by installing extensions in Joomla! will be owned by the Apache/PHP user and your FTP user will not be able to modify them. Here is an article discussing the problem with a couple of possible solutions:
http://docs.joomla.org/Why_can%27t_you_install_any_extensions%3F#File_ownership_advice_from_ianmac
In the past, I have used an Apache Module called suPHP (http://www.suphp.org/Home.html) to solve this problem and keep it from reoccurring. suPHP executes PHP scripts with the permissions of their owners.
As for file permissions other than ownership, please refer to the Joomla! documentation for the correct settings: http://docs.joomla.org/Verifying_permissions. One quick way to handle this (if you can install extensions after correcting the ownership issue) is to use the AdminTools extension (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087). One of its tools ‘fixes’ the file permissions on your server by resetting them to the Joomla! default.
Good luck!
I created an SQL installation script for my extension and it ran just fine. I was developing the extension with the caches turned off. When I turn the caches on, the installation script doesn't get run, and I can't work out why.
I've tried clearing all of the Magento caches through the admin panel, flushing the cache storage, manually removing the contents of the magento/var/cache folder, clearing the APC cache, clearing the redis backend from the command line and restarting the PHP process, and nothing has worked. The only way I've managed to get the installation script to run is by turning the caches off.
Does anyone know why this would be happening? I'm using Magento v1.4.0.0 RC1.
An installation-script should run only once, and only if you tell Magento to do so by updating the version of your modules config.xml. This config gets cached, so clear all your caches and reload a page... It should run the installation script.
You can always reset the way Magento is used to run installscripts, by resetting the version for your module in the database (in the core_resource table of your magento database).
Update scripts are run by Mage_Core_Model_App::_initModules() method, but only when the cache is empty or disabled.
So make sure that you do not access the module configuration in any way before the Mage::run() call in index.php.
When I run the Magento Compiler process it completes fine and then it's enabled. Everything is fine on the frontend until I add something to the basket, it goes to a white/blank screen, same for the basket page and checkout page.
I've tried uncommenting the ini_set('display_errors', 1); line in the index.php file but still nothing is returned. I've also tried showing errors via the .htaccess file without success.
The website's php limit is 256M, so that shouldn't be an issue because the website is empty at the moment.
Really don't know what to try next to debug this? As it just returns nothing and the error logs are empty (CONFUSED!). I've disabled and removed all the 3rd party plug-ins I've used, that appears to have no effect. And I've successfully used those plug-ins I have on other sites with compilation without any issues.
Any help or pointers would be much appreciated! I'm running Magento CE 1.6.0
I finally worked out what was causing the problem!
I've you go to Admin > System > Configuration > Customers > Persistent Shopping Cart
And then disable it, then the checkout whitescreen error goes away!
Have you set it up to use https for checkout/accounts? And if so have you set the base https server to the correct value? If you have told it to use this but not set it up correctly you may get problems.
I'm having exactly the same issue, although I think I've tracked it down to a 3rd party extension. No errors in either the Magento or server logs, and a whitescreen or 500 internal server error, on add to cart or checkout.
The irritating thing is that although I've found references from the developers saying their plugin isn't compatible with the compiler, it seems work on my test system with the compiler.
Could your case be something to do with file permissions?
are your includes folder and subfolders writable?
The compiler doesn't seem to return an error is it can't create a new folder for a module, it just doesn't collect that module, maybe you have an in-house modification that's not being picked up?