I know it has something to do with the persistent feature of Magento, introduced in CE 1.6
But what is the in-depth meaning?
Why is Magento doubling templates?
Those are used for persistent cart functionality and yes it doubles a lot
Indeed it's not responding to much of any of the following: flush cache, cleared (rm -rf var/cache/*), reindexing, flushing service provider cache (memcache), removed session files anything. And I kept getting guest login while I clearly reset that to NO Mage keeps me streaming this JS with wrong information. Cause? Yet another (100's of options of everything) solution that doesn't work and hide information from the user.
I use ArchLinux ffs, I code in Clojure... why does god punish me with a job to work this magic, black-hole OOP soup of beyond proportions :(
Related
I am running Magento 1.8.1 with embeddedERP extension.
Not sure if extension is to blame for the behaviour, i don't think so as it seemed to work fine for a while after I installed the extension. The issue appears to relate to indexing.
I reindexed the site in response to a magento index aler. When I try to view products in the backend the page is blank but only from from the horizontal line below the Add New product button, there is no list of products but also no products table at all, rather than the products table with no rows one would expect.
I have tried deleting cache and session folders.
I've tried disabling cache.
I enabled logging and there isn't an exceptions.log file so presuming this means no exceptions happening.
I've logged in and out.
On one occasion when i tried creating a new product after saving it it displayed the products (new one and existing) but now that doesn't work either.
Previously, deleting session and cache and logging back in appeared to work but now doesn't.
Can anyone suggest how I can go about working out what is wrong. My magento debugging skills probably need some enhancing.
Thanks,
Came back to this and the site was then displaying an error:
Warning: Unknown: Unable to allocate memory for pool in [filepath]/Autoload.php
This thread:
http://www.magentocommerce.com/boards%20/viewthread/216180/#t462005
highlighted this is as an apc issue.
Altering the memory size to 256M as suggested solved this.
Hope this helps if anyone else gets this, still don't know why this issue showed a blank screen to start with, perhaps an APC caching issue?
Can someone please explain why ?___SID=U is appearing in some Magento URLs on my site and not others?
I think it has something to do with sessions but I am not entirely clear. Also, what makes it more confusing is the fact that it's only appearing in some URLs and not others.
I don't need to know how to remove it as I am aware of the setting in the admin area. I would really like an explanation of what it is, what its purpose is and why it would show on some pages and not others. id rather understand what's going on fully than blindly follow some advice as to how to remove it.
I addition to Brendan's answer, the ___SID=U is used in the cache as a placeholder for the session ID. It is replaced by Mage_Core_Model_Url::sessionUrlVar() which in turn calls Mage_Core_Model_Url::sessionVarCallback(). These methods are called from Mage_Core_Block_Abstract::_afterCacheUrl(), which means that any URL found in block output will contain the correct session ID (if needed).
So to get rid of the parameter in your own code the "right way" use this:
$url = Mage::getUrl('some/magento/route'); // might append ___SID parameter
$url = Mage::getModel('core/url')->sessionUrlVar($url); // process ___SID
If the string still displays in the rendered page that is a bug. Are you using some custom caching module, or generating URL's using a non-standard way?
The SID is a "session ID". Magento uses this to track a user's activity within the same Magento installation. Normally, Magento powers one website and one store from one installation (database).
Magento could power multiple websites with multiple stores from one installation though. The SID allows users to stay logged in while navigating across these websites/stores.
I think if you have the function enabled, the SID is sent when accessing catalog URLs so Magento can update the session with the user's location/state for the current website/store.
If you're not running a multi-website or multi-store environment, it's safe to disable the SID on the frontend.
Just something i come across today and though i make a comment, maybe it will help someone.
I found that Magento will format/create an incorrect product url (inc. Session Id) if there were some errors during processing the page. This is not consistent though.
It worth having a look at your server logs for PHP errors.
This is a general Magento 2 bug which is already reported to magento.
Temporary fix is
Go to Document Root,
Find .htaccess and add
RewriteCond %{HTTP_HOST} ^abc.com
RewriteRule ^(.*) www.abc.com/$1 [L,R=301]
below.
This should solve the issue. For me this work in M2.1
All the best.
Reference : https://github.com/magento/magento2/issues/5517
I hunted for hours to find this and the precise answer was a combination of the other answers listed here. First, I cranked up my PHP error reporting and error logging (thanks Gergely Varga). I saw this:
PHP Fatal error: Call to undefined function mb_strrpos() in /var/www/html/app/code/local/ManaPro/FilterAjax/Model/Observer.php on line 59
So, one of our installed extensions requires the php-mbstring package, which my server didn't have installed. As soon as I installed that, the SID=U URLs all disappeared. (In future I'll be running Magento's pre-install checks before copying an existing install over to a new server!)
Thanks to Vinai too for the background of what this tag is for.
Go to Store > Configuration > General > Web > Session Validation Settings > Use SID on Storefrontand and set the value to No.
Clear the Magento cache
I was wondering if anyone could help me with the following issue. On our Magento site, enterprise version 1.10.1.1, a user may log in, and it will say another person's name. Then, if you click on another link, it might go back to your name. The user sessions are clearly being confused. Apparently, this is a full-page caching problem, because our full page cache is often invalidated and, if we turn it off, the user sessions no longer mix up. However, turning it off considerably slows down the site. Switching the sessions from db storage to file storage (and vice versa) did not fix the issue. Does anyone know what the problem could be or how to solve it?
Thanks very much,
Brenda
You should check with Magento for a patch. I had a similar problem with Gift Certificate field info getting mixed up between sessions. They provided a patch that resolved the problem.
In the header.phtml file you should use this to print the user name
<?php echo $this->getChildHtml('welcome') ?>
Then, you can override the block 'Mage_Page_Block_Html_Welcome' if you wanna customize your message.
this happens when you use "Full Page Cache" because by default, magento exclude some blocks of the full page cache, and the block 'welcome' is one of they. if you are using customization code and message, the user name will be cached too, and other users will see different user names in this section.
it can be dependence on the cache issue. Try to turn cache off (go to admin, system, cache management and disable all cache).
If issue gone - you need to check cache configuration. If not - you have really session issue.
BTW, where you store sessions (files or DB or memcached?)
I found the cause related to Enterprise_PageCache_Model_Processor_Default class, my way is disable it in config.xml, edit src\app\code\core\Enterprise\PageCache\etc\config.xml:
<requests>
<!-- <cms>enterprise_pagecache/processor_default</cms>-->
</requests>
This problem was probably caused by Magento not being able to set proper session parameters if it was behind a reverse proxy cache like Varnish (I bet it was the case). Whenever using an intermediate caché system you have to make sure you are using the apropiate module in Apache to forward the X_FORWARDED_FOR http header to Magento like mod_rpaf, otherwise Magento will see al requests coming from the same IP and it will not be able to determine correct session isolation as it will think all requests come from the same client.
For some reason, when I log into my joomla 1.6 backend, it is now empty, displaying only a logout button. Any Ideas?
I just went through the same problem but on J!1.7.3. There may be many, many reasons but please check using just URL if you can see for example:
[YourDomainHere]/administrator/index.php?option=com_content or
[YourDomainHere]/administrator/index.php?option=com_modules
If content is listing and you're missing just Admin-menu and sub-navigation in back-end --> this means you messed-up with access levels and viewing access.
If you can't see content listing - ignore the rest of this post :-)
...with access levels and viewing access. To check that, try entering [YourDomainHere]/administrator/index.php?option=com_users&view=levels and enter each position in the list. Joomla backend navigation module usually has Access set to Special, so focus on this one. When enter Special - manager, author and super administrator should be ticked. If everything empty in any from the list - this is your issue :)
You need to add manager, author and super administrator to your Special access level. Obviously you can't see Save button, so you need to use database. [wrrr :) sounds scary?] Not a big deal, just go there using for example phpMyAdmin and find _viewlevels table. In there just edit Special and add [6,2,8] values to set up manager, author, super.....
Update database. Try to log-in one more time (close browser and clean cache before).
I hope if this wasn't helpful for you, will be for somebody else.
p.s. There may be a way of 'saving' changes in you joomla access levels with URL. Then you don't need to go to DB .. but I don't know if this is feasible at all :)
Check the rewrite of htaccess and the $mosConfig_absolute_path variable in config.php
Apparently, the Bluestork Template (admin template) has some security issues. In my case there were some missing files in the template folder /administrator/templates/bluestork/ that caused the administrator screen to appear blank. I've copied a clean version of the template in the bluestork folder and after that I was able to see the backend admin area.
I've removed the bluestork templates entirely for now, which seems to be the best option. Joomla installs 2.5.8, 2.5.6, 2.5.2, 1.7.0, 1.6.3 are affected. The Blustork Template is a target for hacks with old Joomla.
this happening becoz of admin user lost his permissions. see below article to fix this issue
http://www.codentalk.com/joomla-admin-showing-blank-page/
I have a problem with debugging a thing (not a real error) in Magento (CE 1.4.1.1).
For a payment module I've adapted, some additional payment fee is incorporated and is showing up on selection of the particular payment method. Works fine, no problems.
A client has the OneStepCheckout plugin installed. Inside it, the payment method works fine too (small problem: payment fee is showing up after the grand total, but that's not the issue, just for completeness of my question).
So, everything is working fine, even with some other payment modules installed. That is, working fine on dev and test! On the live server however, the extra fee does not show up! I've locally installed the other plugins that are installed on the live server as well, to see if there are any conflicts among them. None whatsoever. The Extension Conflict extension does not indicate any class overwriting problems either. Of course, I've cleared the cache. Several times.
So my question is a rather general one:
How to proceed?
What can I do and how to actually see what's going on and NOT break the live environment ? As far as I know, there is no staging server (there is a test server, but also there no error...), so I'm bound to the live environment.
Is there a common practice to handle these kind of issues? (And if so, what is it?)
I know of the MAGE_IS_DEVELOPER_MODE, system log, exception log etc, but since on dev everything works fine, I seem to not be able to really debug a bug which does not show up... can I safely switch on the logging on a live site by the way?
Thank you all in advance!
Regards,
Tom
You can create your own log to see what is happening in Magento
Mage::log($datayouwanttosee, null, 'yourlogfile.log');
This will not break anything but will show you anything you want from that file. Once you load the page 'yourlogfile.log' will be in Magento's /var/log directory with the other log files.
Also make sure to turn your logging off when you are done otherwise the log could consume a lot of disk space.
You have better results if you contact OneStepCheckout support directly with this issue. Also verify that you ar using the latest version of OneStepCheckout
Totals however have sort ordering and this is available in Magento admin under system > configuration > sales > sales > Checkout Totals Sort Order