Why it is sometime necessary to do Cache management to disable and Index management to re-index in magento.I am new in magento so if you know then reply this kindly.
In your development environment its advised to disable the cache because you tend to make the changes in the template / layout files often so to get it reflected on the frontend / website you are advised to disable the cache in your development environment. But don't do it in PRODUCTION.
And coming to Index Management, set it as "Save on Update" mode so that each time if you make some changes to your products, categories or attributes its getting re-indexed automatically and avoids the necessity to re-index it every time manually.
Specifically, "Block" data are the html blocks that the MVC generates to present to the frontend and even in the admin sometimes. Because of the caching and also session information, you need to log out of admin and back in for some changes to appear.
Depending on site volume, there might not be a penalty for turning off caching. If I'm doing a quick styling fix, I'll disable the block cache for a couple minutes.
Related
I have a snippet that updates some system settings by updating and saving modSystemSetting objects. I noticed that old settings are still coming from the cache.
Clearing the cache works:
$cacheManager = $modx->getCacheManager();
$cacheManager->clearCache();
But this clears the whole cache which isn't good. How could I clear only updated settings? Clearing all systems settings would work too.
Checkout the refresh function in modcachemanager.class.php, look at each of the $providers.
For system-settings try to start with $cacheManager->generateConfig() and see from there. Maybe you'd need more then just the system settings, like context settings, etc..
If you go further, checkout using custom cache. You can delete specific keys in the cache $cacheManager->delete($key). See the Programmatic (Custom) Caching
I am working with a Kentico site and I have a problem with page output caching.
We have a custom webpart which loads the records from a Bizform's record data and displays those data in a page. The problem is that after giving it several tries, we couldn't figure out the problem why the webpart couldn't get the latest data from the bizfrom data and we suspect it was because of output caching.
We tried to:
Disable webpart output caching in webpart configuration
Disable page output caching in CMSDesk > General > Output Caching
Disable site output caching in Settings > System > Performance
Disable IIS cache for both User-mode and Kernel cache
Create cache dependencies for cms.form|byid| touched key (which I found is not supported in current kentico version)
And going to try create event handler to add touched key on bizform insert event
We encounter a similar problem with Shopping Cart Mini Preview Webpart with Ecommerce.CurrentContext.CurrentShoppingCart which returns different result for service handler (.ashx - gets updated) and for webpart (.ascx - does not get updated)
If you ever experienced these problems, please help.
The last place where it could be cached is the content cache. It can be set either in Settings->System->Performance or at the web part level under System settings section.
Only web parts that utilize the content caching have this section available. (E.g. some repeaters and data source web parts.) It might be a little bit confusing because then there are two sections (System settings and Performance) where you can influence caching. However the Performance section is used to set up the Partial output cache.
Anyway, you should definitely try to check Cache debug to see what is actually cached.
Additional resources:
Deep dive – Kentico CMS Caching
New in 5.5: Caching API changes
Deep dive: Cache dependencies
Kentico caching and cache dependencies explained
ASP.NET Caching Dependencies
I have faced issue similar to second one (with Shopping Cart Mini Preview Webpart) recently. Only web service (.asmx) was used instead of HTTP handler. In my case issue was solved by setting the EnableSession property of WebMethod attribute to true for all the CRUD webservice methods.
[System.Web.Services.WebMethod(EnableSession = true)]
So I think the matter is that handler should be able to access current Session.
In case of HTTP handler you could try to add IRequiresSessionState on the handler declaration to attach it with the session.
I am also using Kentico 8, I see that your Kentico version is older. That might also have impact but I am not sure about that.
In the TYPO3 backend, I can clear different kinds of cache: frontend caches, general caches, system caches... Furthermore, there are also options to clear caches in the install tools.
In many cases, especially when I develop an extension, I need to clear the caches to reflect the changes I made. However, I never really know which caches I need to clear, and most of the time, I clear each one until I saw the right output when reloading the page. In other cases, when I upgrade TYPO3 for instance, I need to clear the caches from the Install tools, otherwise it looks for php files in the old installation path.
What are the different kind of caches that can be cleared? What is the difference between each of them? Which files or database items each command clears? In which case each clear caches command is necessary (i.e. when modifying which kind of file or information)?
In TYPO3 6.2 and 7:
You can see the configuration of all caches in the backend System > Configuration in the SYS.caching.cacheConfiguration section. Every cache is registered in one or more "groups": all, system, pages. The menu items reflect these groups:
"Flush frontend caches" (cacheCmd=pages): Clears frontend and page-related caches. This makes TYPO3 re-render content which is usually cached (everything except USER_INT objects)
"Flush general caches" (cacheCmd=all): Includes frontend, plus some caches registered by extensions with clearAllCache_additionalTables (i.e. news cache, realurl caches). Despite being all it does not include the system caches (and this is why it is called "general caches" and not "all caches" in the menu).
"Flush system caches" (cacheCmd=system): Clears "system-related caches", including the class loader, localization and extension configuration file caches.
Install tool "Clear all caches": This is a hardwired to "remove all typo3temp/var/Cache files", and also all MySQL cache-tables ("cf_*", i.e. Extbase Reflection). Then it goes through all registered Caches and clears them all too.
So best is to get yourself aware what parts of your code are stored in which cache so that you understand what to flush when you change something:
PHP classes in Extbase have their content parsed in so called "Reflection Cache" (i.e. the annotations) => Flush system cache.
You extension settings ext_tables.php, ext_localconf.php, TCA are cached in the cache_core => Flush system cache.
Your fluid templates are compiled into PHP code => Flush system cache.
Your PHP code might be cached by the "opcache" of your PHP. Usually opcaches are configured to check for the modification time of the file, so usually you don't need to flush any opcache after modifying PHP files. This might not be the case in some scenarios, or if there you work through symlinks of the system time is not synchronized, then you might need to flush opcache after PHP code change => Install tool clear all cache.
Your TypoScript is also cached (cache_hash) => Flush frontend caches. Note that if you change TypoScript in the backed, this will automatically flush these caches automatically.
If your change will also affect the cached output that is rendered to the frontend, you might also need to Flush frontend cache. To avoid this you might set in your TypoScript: config.no_cache = 1.
Please note that since TYPO3 8.1 the menu in the backend and the whole system has been simplified, so we only have left:
"Flush frontend caches": Clears frontend and page-related caches, like before.
"Flush all caches": Does more or less what the install tool previously did. This will thus include also all extension caches, reflection, system caches. Since it includes the "opcache flushing", also PHP file changes would be reflected here.
To ease development without caring about some of these caches, you might want to turn them individually "off".
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pages']['backend'] = NullBackend::class;
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_pagesection']['backend'] = NullBackend::class;
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_hash']['backend'] = NullBackend::class;
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['extbase_object']['backend'] = NullBackend::class;
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['extbase_reflection']['backend'] = NullBackend::class;
See: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/CachingFramework/Configuration/Index.html?highlight=cache#how-to-disable-specific-caches
In very general you need to clear frontend and general caches when changes made in the record (by editing) aren't reflected on page (because page is cached).
system cache additionally keeps different configurations from extensions (all these stuff from ext_tables.php, ext_localconf.php, language files, etc.) so you need to clear it when doing changes in these files... but also when injecting for an example new repository to the controllers.
TIP: there's some plugins for the browsers which displays cache clearing icon (a.k.a. Yellow Flash) in the address bar, i.e.: TYPO3 Clear Cache for Chrome
as noone mentioned the files yet:
there are a lot of temporary files which could be removed anytime, and must be removed sometimes. partially they even are included in the cache clearing from the BE.
the base folder is /typo3temp/
caching is done in /typo3temp/Cache/ which is divided in /typo3temp/Cache/Code/ and /typo3temp/Cache/Data/
here are gathered the concatenation of some php-files (e.g. ext_tables.php)
since 7LTS there is another folder which needs manual deletion sometimes: typo3temp/autoload/ where class-information is stored for autoloading. Especially if you develop new extensions this folder is not cleared automatically on each edit.
In magento, there is a option is available by which we can stop caching.
my question is why cache files are created,if we disabled the cache? and my second question Is there any way by which we can prevent creation of cache files.
There are some things cached in Magento even if the cache is turned off.
Here are some examples.
the language select in admin footer: Mage_Adminhtml_Block_Page_Footer::getLanguageSelect
the admin notification config field: Mage_Adminhtml_Block_System_Config_Form_Field_Notification::_getElementHtml
admin notification last feed update: Mage_AdminNotification_Model_Feed::getLastUpdate
last cron execution: Mage_Cron_Model_Observer::generate
and specially the table schemas. this is done by ZF itself
...and there are others.
The solution for this would be to override the methods Mage_Core_Model_App::saveCache and Mage_Core_Model_App::loadCache to not save anything or not return anything when you want it disabled completely. But I don't think this is a good idea because it might affect some parts of the application.
To ensure that the cache has been completely cleared, click the Flush Magento Cache and Flush Cache Storage buttons in the upper right hand side of Cache Storage Management menu.
I need to clear the IIS cache on my server. The exact reason is detailed below; but the reason doesn't matter. I'm 100% sure that this is the solution I need; as detailed below, I have used the process of elimination to determine that this is, indeed, the problem I'm facing, and the solution I need.
I have an MVC3 app that's themeable (skinnable architecture). Think of it as Wordpress; users can develop a theme, download it, and activate it on their site. The theme controls exactly the final HTML output. This is an over-simplification, since I provide an API with useful functions to be consumed by themes.
Anyway, users can change the theme of the site. The theme is currently stored in a static variable. When a view page is rendered, the name of the theme determines the location of the layout file (which contains references to the CSS files, etc.) and the view files. The theme is a setting that persists in the DB.
For example, if I have a theme called "Foo", then when requesting the /Admin page, I might use /Themes/Foo/Admin.cshtml. If I have another theme called "Bar" which does not have that file, then for /Admin it might request /Themes/Bar/Generic.cshtml as the layout.
The problem is that changing a theme means that every single page on the site is outdated. This means that any sites cached on IIS7 will show the old theme; this is incorrect. I need them to show the new theme.
Anyway, IIS7 uses caching by default. I need essentially a way to clear the cache when a user changes the theme. Currently, this is not happening, and users continue to see the old theme until the cache (somehow) expires itself.
I am not using output caching, or any other form of explicit caching; this is a "vanilla" ASP.NET MVC3 application from a caching perspective (i.e. I didn't add/configure any caching). IIS7 has its own default caching. I know this, because if I disable output caching in IIS7 for my Site, I will always see the correct theme after a change.
How can I flush the cache? Other SO questions point to using Cache.blah, and I tried using HttpContext.Current but that is null during tests (using VS test tool) -- because the ASP.NET pipeline is not used in full.
To explain, in an integration test, I basically:
Go to localhost/Test/
Log in (submit values into the forms)
Change the theme by browsing to the right page and clicking the right link
Request another page
See if the theme changed (based on the layout/css file name).
This is all done by code; I use a C# port of HtmlUnit, and along with deploying my app to /Test in IIS, I can essentially browse it like an end user.
Currently, this test passes around 50% of the time. The problem is that IIS is caching the results, and I can't cleanly reliably reset the cache on the server-side.
Again, I'm not talking about clearing the session or the user-side cache; IIS itself is the culprit guilty of caching my application. Nor do I want to completely disable the cache via the IIS settings, a) because I can't force people who install my application to do that, and b) because caching is good.
So how can I force flushing the cache on the server?
For example, I tried programatically touching web.config; this works, but recycles my application pool, and so, kills my static variables; every request means reloading all the static vars from the DB, which kills my performance.
As you requested I have amended this post:
You can use output cache, you say that the selected theme is stored in the database ( like settings for the site ) Well I would add another column with say a GUID and then use this as the varybycustom value.
Your global.asax file will be able to run code:
void Page_Init() {
///code here to get the GUIDforthissitestheme
var outputCacheSettings = new OutputCacheParameters() {
Duration = Int32.MaxValue, //think its maxvalue
VaryByCustom = GUIDforthissitestheme
};
InitOutputCache(outputCacheSettings);
}
At least here you will have output cache, but also every change of theme, changes the GUID so therefore changes the cache and then your page should be new.
I did something like this on a site that listed products, and when the products database was updated the key would be changed, however I can't find what site I implemented it and I work on a hell of a lot of sites.
hope this helps
Set up 'Cache Rule' in 'Output caching' feature with 'File Cache Monitoring' set to 'Using file change notification'. Then 'touch' the files theme change affects, from .net code you could do:
System.IO.File.SetLastWriteTimeUtc(fileName, DateTime.UtcNow);
The issues you are describing sound a lot like a client side caching issue. Have you checked this with a HTTP Proxy like Fiddler to verify if this is getting cached on the client?
If you are seeing HTTP 304's after a template change you may want to try configuring IIS (or your site template) to disable client side caching.
I dont think the approach mentioned for themes is correct.
If we are using STATIC variables , then it will affect all the users and all the pages.(Which is certainly not required.)
We can think of two approaches,
Use theme name in url and make it as a prat if RouteData. So the url "http://myHost/BLUE/.." will return in BLUE theme and "http://myHost/RED/.." will return in RED theme. If user will change theme then url will be updated.
The problem with above approach is next time user browse, it will load default theme.
So better approach will be save theme as a part of user preference. Once user logged in read the theme from DB and set the RouteData value.
Just touch web.config. That's the easiest and most reliable way. Flushing the application pool programmatically is overkill.
If you have a problem finding out where web.config is in a test environment (since System.Web.HttpRequest.Current is null, and similar for Server), you can always use an app.config file to point out the location.
Again, there's no other easy way to do it; even disabling output caching, as mentioned in the question, is hard to do through web.config alone.