my broadleaf admin is no updating any change on page content that I make, the inmmediatly deploy always complete succesful, but for some reason is caching the old page, If I clean app´s cache the change is updating and I can see my change and also if deploy manually It clean chache and the change is displaying.
any idea?
Broadleaf uses SOLR indexing for products which runs after every 60 minutes by default. So if you make some changes and even if you don't clean your cache, the changes will be reflected after 60 minutes by default.
If you want to apply the changes quicker for your testing, you can change that by reducing the time specified in the property
solr.index.repeat.interval=
in common.properties of site resources.
Related
I have multiple instances of site that share the same database. I've run into an issue where I reverted a page template to its previous version and on the current site instance it looks good, but on other instances it is still uses the old version. I tried restarting the application pools, sites, database server, but it still does not reflect on other instances. I've tried Kentico's System application to restart the application, clear cache and release unused memory, but nothing works. My Kentico version is 12.0.29.
What am I missing, could you please advise on my case?
After reverting template i needed to check-in some changes that CMS made, and after pulling code my sites are the same again. Seems that Kentico saves some changes to files?
Kentico caches very heavily and this is most likely the issue you're seeing. When you say you have multiple instances, are you talking codebases or what are you talking about?
In the other instances, if you want to see the changes immediately, you need to go to the System app and clear the cache. This should help you see those changes a lot faster.
Kentico caches the data heavily as Brenden said. as per my understanding the template versions you need to verify.
If the versions are same you need to go to system module thenrelease the memory and clear the cache of the system.
We recently migrated a bunch of document updates up from a pre-production server to our production server. We'd attempted to use content staging, which had worked mostly OK in the past, but this time it failed with a lot of parent records not found errors. Our outsourced developer used the Documents tab of the Staging module to sync subtrees across. However a few files got missed, or didn't work correctly the first time. So I'm trying to move them now, and I'm running into a problem.
After expanding the content tree and clicking on the document in the Documents tab, and selecting the correct target server (we've got bi-directional staging set up), we're getting an error: Dependent task 'Move document See Things Differently' failed:Synchronization server error: Exception occurred: SyncHelper.ServerError: Document node not found, please synchronize the document node first.
Looking at the tasks listed, I don't even see a Move document task anywhere queued up for the target server.
Is there any way I can move this document up to our production instance? I've looked at the site export as an alternative, but it doesn't look like I can export just this one page. Am I going to have to recreate the page on Production instead?
The best way is to attempt this sync is to clear out all the staging tasks and do a full sync from the root of the website. Most likely what happened to some of the documents which are stating "moved..." is the pages were reordered. Which means every document below that document's parent will be updated on that level. So simply moving or reordering one document out of 10, will trigger 10 staging tasks. If you don't sync those to the production site, the order will be off according to the staging site.
I have had a problems similar to this before.
This typically works:
Create a copy of the document, put it in the same location in the
content tree.
Delete the original document.
Make any changes to the new document name, URL, aliases, etc (remove the '1' for example)
Then push that new document with Kentico Staging.
Its a bit of a hack but sometimes necessary.
Brenden is right on target about clearing the staging tasks listed under "All tasks" before you try syncing again. We've run into these errors on our sites when we've tried pushing a large number of docs from staging to production. What worked for us was deleting all pending and failed "Pages" tasks, then under the content tree in "Pages," navigating to the first child level and syncing "Current page" all the way to the closest parent directory, and then syncing "Current subtree."
For instance, if the problem doc is in, say, the "18" dir, select Articles and sync current page, then 2016, then 01, and for 18 sync current subtree.
content tree syncing screenshot
The best way is to use Kentico in-built Staging module and use that to first move objects and then the pages.
I have never faced any problem moving a large number of nodes(around 8000). That's the best possible approach.
In case your website a large no of custom table items let's say 50K, then I would do an export/import of the table. Synching so many entries usually has given Connection Time Out error before.
Thanks,
Chetan
Does anybody know what Liferay's reload interval is for portal-log4j-ext.xml and if there is none how to configure one? My goal is to change the log level for certain packages from e.g. WARN to DEBUG without bouncing the server.
I'm not aware of a reload interval. But you can go to Control Panel / Server Administration. There's a tab containing Log levels and you can change the existing ones or introduce new ones. They'll be active immediately.
Caution: Upon restarting the server, the settings are lost (by design) and you'll start over with the file-based logging configuration. But as restarting is not an option for you, this should solve your problem. Of course you're still free to edit the file so that your settings will become active by default on restart.
I have a uCommerce package installed for my sitecore. The problem exists when you start editing template items under sitecore/templates/User Defined/uCommerce definitions/. When you restart IIS or recycle application pool (apparently this happens after solution rebuild) the template items reset their values to the fixed one. What could be causing the problem? Is there any cache mechanism which could be causing this?
update: have checked the sitecore database, the field values are being saved and stored in database properly after iis reset/pool recycly, so there is pretty much confidence that it has to do something with caching
The UCommerce DataProvider (UCommerce.Sitecore.SitecoreDataProvider.DataProviderMasterDatabase) automatically adds the templates under sitecore/templates/User Defined/uCommerce definitions at start up so they will always be reset after each recycle.
First off, make sure that you are making your changes in the Master database and not the Web database. If that is not the issue, then try the following while logged into Sitecore as an administrator:
Go to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the Sitecore cache
Go to the Master database's content editor and look at your templates
Make any changes necessary, save and publish
Do your IIS restart / application pool recycle (the latter occurs on every build)
Go back to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the cache again (just a base-case)
Go back to the Master database's content editor and look at your templates again
If the issue occurs after trying those steps, then you should open a Sitecore support ticket and see what they say. You may also want to try making a clean install of Sitecore and trying to reproduce the issue there (Sitecore Support is likely to do this as well).
The problem was that the standard values template presentation layout I have been updating was the english version. However, there was another language version set and the layout for that version was different. When uCommerce is resetting the template on application pool recycle it doesn't take into the account the multilanguage support, so the last retrieved language version of that fieldvalue is used as reset template and that different language version with different layout was used. A partial workaround is to use the same layout for all the language versions.
I have a strange problem in drupal. When I'm trying to change _any_ setting in the drupal admin (caching under performance, temp-directory under file-system, default filter under filters, etc) I get the message that the changes were saved successful, but the values don't change.
I don't know where to start debugging since this is such a widespread problem. I've checked rights of all files/folder and the database connection. Seems fine.
Anyone experienced such a problem before?
edit: There isn't a single error entry in the drupal log file.
edit 2: I just deactivated every single contrib module. Still I can't make any changes to (for example) the caching mode.
Clear the cache in application and check again .. You can find it from
Drupal 7: Administration > Configuration > Development > Performance (admin/config/development/performance)
Drupal 6: Administer > Site configuration > Performance (admin/settings/performance)
Click “Clear cached data” button below