I've got a very strange cache problem.
IÄve got one store with two languages. When i change the language from German to English, it's working the first time. So when i'm on side A(German) it switches to A(English). But.... if I change the page or the category... in example, from A to B and THEN i switch the language again, it redirects me back to A and not to B.
It's a very strage cache problem. I deactivated all cache options and afterwards it works perfectly but I cannot run a shop without any cache possibilities:
here's my shop: http://www.livewire-clothing.de/packagedetails/
Check out the page code. Switch the language and the page and check the code again.
This part never changes:
<select id="select-language" title="Ihre Sprache" onchange="window.location.href=this.value">
<option value="http://www.livewire-clothing.de/merchandise/k.html?band=78&manufacturer=55&size=39&___store=de&___from_store=de" selected="selected">Deutsch</option>
<option value="http://www.livewire-clothing.de/merchandise/k.html?___store=en&band=78&manufacturer=55&size=39&___from_store=de">Englisch</option>
</select>
It must be the cache.
Does someone got a solution for me or could help me out? Thank you very much.
The problem is most likely that you put the language switcher in the footer block. The footer block in Magento has block caching activated. If you take a look at Mage_Page_Block_Html_Footer , you will see a cache key defined (Magento 1.5):
public function getCacheKeyInfo()
{
return array(
'PAGE_FOOTER',
Mage::app()->getStore()->getId(),
(int)Mage::app()->getStore()->isCurrentlySecure(),
Mage::getDesign()->getPackageName(),
Mage::getDesign()->getTheme('template')
);
}
This means the block output will be cached in separate versions depending on the current store, design etc.
However, your language switcher links directly to the current page in each language. When the link is different for each page, your footer output will be different for each page. I would recommend simply disabling block caching for the footer block by overriding the block and remove the cache definitions, or by using a core/template block instead.
Related
I followed the instructions from this post on how to create dynamic items in APEX. The documentation is clear on how to create the item but I cannot figure out how to make the item look like native APEX items.
I have attempted copying different CSS classes that I can see attached to the native items, but for the life of me I cannot get my dynamically created form elements to look and act the same.
Any help would be greatly appreciated.
Hi – just to add to Dan’s and Salim’s comments and recommendations. I agree that for this particular use case, APEX_ITEM work well. However, as Dan pointed out, the APEX_ITEM API is considered legacy code. While we may never actually remove this API from APEX, as this would break too many apps, we do not plan on developing this API further. There are many reasons, but really comes down to the APEX_ITEM API using its own code to render page items, and all new components, including standard form items and Interactive Grid form items, share the same, more modern implementation, which is fully integrated with the Universal Theme and accessible. There are also significant differences in the way form items are submitted to the server and the way this data is processed. We’re working towards providing better alternatives to the APEX_ITEM in the future.
- Marc
If you are using Chrome Browser, then the easiest way to get all the styles is to use the browser Copy styles.
Right click on an item created natively and select Inspect.
Right click on the selected HTML element under Elements tab and go to Copy => Copy styles
This will get you the styles associated with the native item. Now assign those styles to your dynamically generated item.
You need to do this for every item type.
Best Regards,
Salim
This should help:
with
TP_ORDEM_SERV_REC as (
select C.ID_FUNCAO,
C.QT_EXEC
from TB_ORDEM_SERV_REC C
where C.ID_ORDEM_SERV = :P922_ID_ORDEM_SERV
and C.NUM_TAR = :P922_NUM_TAR)
select A.DESC_SUPLEMENT FUNCAO,
'<div class="t-Form-fieldContainer t-Form-fieldContainer--floatingLabel lto'||A.ID_SUPLEMENT||' apex-item-wrapper apex-item-wrapper--text-field" id="it_'||A.ID_SUPLEMENT||'_CONTAINER">'||
'<div class="t-Form-labelContainer">'||
'<label for="it_'||A.ID_SUPLEMENT||'" id="it_'||A.ID_SUPLEMENT||'_LABEL" class="t-Form-label">Quant. Exec.</label>'||
'</div>'||
'<div class="t-Form-inputContainer">'||
'<div class="t-Form-itemWrapper">'||
'<input type="hidden" name="f01" value="'||A.ID_SUPLEMENT||'" />'||
'<input type="text" name="f02" id="it_'||A.ID_SUPLEMENT||'" class="text_field apex-item-text" value="'||A.QT_EXEC||'" size="1" maxlength="2">'||
'</div>'||
'<span id="it_'||A.ID_SUPLEMENT||'_error_placeholder" class="a-Form-error" data-template-id="'||A.ID_SUPLEMENT||'_ET"></span>'||
'</div>'||
'</div>' QT_EXEC
from TB_SUPLEMENT A,
TB_USUARIO B,
TP_ORDEM_SERV_REC C
where A.FLAG_CTRL = 15
and B.ID_OFICINA = :P922_ID_OFICINA
and A.ID_SUPLEMENT = B.ID_FUNCAO
and B.ID_FUNCAO = C.ID_FUNCAO (+)
group by A.DESC_SUPLEMENT,A.ID_SUPLEMENT,C.QT_EXEC
Then, just use apex_application.g_f to manipulate the result in the process as normal.
In Magento EE I need to redirect customers depending Origin country, browser lang and previous preference set in a cookie.
I have huge problems making it work with FPC.
I tryed to observe the controller_action_predispatch event, but FPC somehow caches my redirect instruction and customer is not redirected.
I then tried another solution: extending the run() method in Mage_Core_Model_App in order to perform operations before FPC starts to work.
Unfortunately, I don't know why, inside this method you can't access Mage::getModel(), Mage::helper(), Mage::getConfig() ecc
Can you help me please?
Thank you
I've recently been through exactly the same pain. You are on the right track;
controller_action_predispatch
Is the correct event to observe, and you can use this quite happily if you are redirecting to a category or product page with FPC enabled. The problem is the home page - which is a cms page. The cms page cache does not fire controller_action_predispatch. I got around this by adding this to my observer;
public function switchUser($event)
{
// CMS page bug, disable FPC to still use observer
$action = $event->getEvent()->getControllerAction();
if($action instanceof Mage_Cms_IndexController) {
$cache = Mage::app()->getCacheInstance();
$cache->banUse('full_page');
}
// do the rest of your code here
}
The blocks within the cms page will still cache so the page is still nippy, though obviously not as fast as it would be with full FPC enabled. Its a sound trade off in my opinion.
I'm trying to display a static block in Magento as a popup window, but can't seem to get the code to work.
I've found code in various places on the internet that seems to be fairly close to what I want but I can't get any results. I've used the basic code to return the "top links" to my site so I know that the basics work.
I've created a delpopup.php script in my Magento root folder and put in this code:
<?php
require_once('app/Mage.php');
umask(0);
$layout = Mage::app()
->getLayout();
$layout
->getUpdate()
->addHandle('default')
->load();
$layout
->generateXml()
->generateBlocks();
echo '<p>before</p>';
echo $layout
->createBlock('cms/block')
->setBlockId('delivery-info')
->toHtml();
echo '<p>after</p>';
?>
Unfortunately the code doesn't display the static block. That part of the output is blank.
The idea is that I can place a link in a regular page in Magento and have my delivery into pop up. Like this:
<a title="" onclick="popWin('http://www.mysite.com.au/delpopup.php', 'deliveryinfo', 'width=300,height=300,left=0,top=0,location=no,status=yes,scrollbars=yes,resizable=yes'); return false;" href="#">Delivery Info</a>
Basically I want to be able to display a static block in a popup window that uses my Magento site's theme. Any ideas would be greatly appreciated.
As I thought, the problems lies on incorrect Block Id.
Now that the cms is able to be shown.
So now the question is: how to get the theme work?
Not really sure what do you mean by theme, if what you mean is css that was included in <default> tag, you can use:
Mage::getDesign()->setTheme('your theme');
echo $layout->getBlock('head')->toHtml();
After the xml has been finished generated, it means put that code after:
$layout
->generateXml()
->generateBlocks();
I'd first setup a controller and block(s) to render the type of layout that you want to throw within the popup. So, instead of doing this within a standalone php file, do it within the regular mage framework within a specific controller action.
Then, once you have that working - the question is how to pull it into a popup. I'd go with maybe a nice jquery popup widget that allows you to specify a URL to hit - and then just pass in the one that you prepped for step 1 above.
You may want to look at adminhtml/default/default/template/popup.phtml for inspiration. That's actually a popup template for the admin, not the frontend, but you can see what they've done.
They're pulling in some standard magento blocks including the head block, which should pull in all your CSS and JS, in order to give you the general color scheme / look&feel of your frontend, but without all of the navigation, etc.
I know how to use Zend_Acl to allow certain resources to certain usergroups but how do i use it to allow only specific parts of the page to be shown? For example
I have a button to delete a post via AJAX on the page but i only want to show the button to Admins only. I can use Zend_Acl to block access to the controller post/delete but i can't use it to block the button from showing.
// in controller
$this->view->allow_delete_post = $acl->isAllowed($role, 'delete_post');
.
// in template
<? if ($this->allow_delete_post): ?>[button html]<? endif; ?>
Would that not do it?
You can also write a custom static ACL class which you can then call directly from within your view script.
Since ACL is normally handled at plugin level it means that if your visitor is seeing the view then ACL has already allowed the resource, therefor inside your view you can now do something like this...
if(My_Custom_Acl::getIsAllowed('some_resource', 'delete_post_action'){
I did not specify the role name in the custom getIsAllowed() method, because at this point ACL is already suppose to know the user's Identity and the Role.
Hope this helps
Although Christof gave a good solution, an alternative is to split the views. Although this starts to violate DRY, when you have about 200 different admin things/controls, it's getting heavy in the view - thus splitting the view with $this->render('view') and $this->render('edit') for permissions from the controller is sometimes easier. Then only the edit view script has the edit links. But again, it's DRY, so not optimal, but an alternative. I guess you have to weigh it up, which one is more DRY, repeating the ACL check or the stuff in 2 views...
I'm making a web app to manage product SKUS. One part of that is to associate SKUs with product names. On each row of a table, I list a SKU and display a <select> box with product names. The product that's currently associated with that SKU in the database is given an attribute like selected="selected". This can be changed and updated via AJAX.
There are a lot of product <option>s - 103 to be exact - and this list is repeated in the <select> on each row.
From another input on the page, I am using jQuery AJAX requests to add new SKU/product associations, and to make it clear that they're added instantly, I insert them into the top of the table with a little highlight effect. As the number of SKUs increases past 10 or so, if I refresh the page (which loads everything back out of the database ordered by product name), Firefox starts to show some wrong options as selected by default. It is not consistent about which incorrect option it shows, but it seems to be mixing up the options that existed before the page reload.
If I inspect the <select> using Firebug, the select="selected" is on the correct <option> tag. Refreshing the page (or leaving and typing this page's URL back in to return) does not make it show up correctly, but hard refreshing (Ctrl+F5) does.
Both Chrome and IE7 display this correctly in the first place.
My theory is that this is a result of a faulty cache strategy by Firefox. Does that sound right? Is there any way I can say in my code "if this page is refreshed, make it a hard refresh - reload everything from scratch?"
Update
To solve this problem, I changed strategies.
Previously, I put a <select> with a long list of <option>s on each table row, with the current value set as default
Now, I put the current value in a <span>. If the user clicks a "change" button, I replace the <span> with a <select>, and the "change" button becomes a "confirm" button. If they change options and click confirm, AJAX updates the database, the and the <select> goes back to being a <span>, this time with the new value.
This has two benefits:
It fixes the bug described above
It requires far fewer DOM elements on the page (all those redundant <option>s)
I had a similar problem, but after adding autocomplete="off" HTML attribute to every select tag it worked. [I was using Firefox 8]
Firefox preserves your selected form elements when you refresh. It's intentional. Ctrl+F5 is a "hard" refresh, which disables this behavior.
--
Or Command+Shift+R if you are on a Mac
An easy way to prevent Firefox from caching the last selected option is to remove all of the option elements on page unload. For example (assuming jQuery):
$(window).unload(function() {
$('select option').remove();
});
I had this same issue. I was trying to change the value of the select depending on which option had selected="selected", but Firefox wasn't working. It would always default to the first option.
Chrome, Safari, etc worked when I did this:
$( 'option[value="myVal"]' ).attr( 'selected', 'selected' );
... but this wasn't working in FF.
So I tried:
$( 'option[value="myVal"]' ).prop( 'selected', 'selected' );
and it works.
jQuery v1.9.1
Although this is old question, but below solution can help someone
In firefox, I've notice that the "selected" attribute will not work unless you place the select inside a form, where the form has a name attribute.
<form name="test_form" method="POST">
<select name="city">
<option value="1">Test</option>
<option selected="selected" value="2">Test2</option>
</selecct>
Again remember :
form must have the "name" attribute and
"select" must be inside the form.
I make it worked by putting the autocomplete="off" on the hidden input.
Firebug has a cache disable function for exactly this scenario.
The deeper long-term solution is to work out how set no-cache headers server side. What web server are you using?
Every time I ever had weird select option bugs in Firefox it was because I had multiple options marked as selected. Are you quite sure that only one is marked as such? Seems like you could get out of wack pretty easily if you are changing that with AJAX.
FYI: in order to stop Firefox from restoring the previously selected option after page reload you can place the entire <form> containing the <select> options inside an <iframe>.
When select boxes are in <iframe> and you reload the container page, Firefox finally behaves like ALL other browsers, by simply resetting select options.
Thanks to #BananaDeveloper (https://stackoverflow.com/a/8258154/2182349) - this is my solution to solve this problem on a single page in an application
I didn't want to customize the off-the-shelf/open source application code
<Files "page_that_does_not_work.php">
SetOutputFilter INFLATE;SUBSTITUTE;DEFLATE
Substitute 's/<select/<select autocomplete="off"/n'
Substitute 's/<form/<form novalidate/n'
</Files>
Apache docs for mod_substitute https://httpd.apache.org/docs/2.4/mod/mod_substitute.html
Thanks to: https://serverfault.com/questions/843905/apache-mod-substitute-works-in-curl-but-not-on-browser for the SetOutputFilter
Replacing jQuery
.attr('selected', true)
with
.prop('selected', true)
for <option> tag fixes it for me. All other solutions didn't work
I've figured out. If you put onunload or $(window).unload (jquery) on your HTML with no-cache header, Firefox reloads the page and initialize DOM even from back button.