We have a Sitecore 6.5 instance with separate CM and CD servers, each uses it's own core, web and master db's as well.
We are seeing issues when a new version of content is created. The CM Master and Web databases show the correct content in the content editor. After a publish, the Web database on CD shows the correct content in the content editor.
However, the website is showing a mix of correct content and standard values.
Some things I've tried and noticed:
Clearing cache manually as no effect.
No publishing or cache errors in the CD or CM logs
We've reviewed the Scalability Guide to be sure CD and CM are setup correctly
Saving the item in the CD content editor immediately fixes the problem until a new version is created and published on CM
Republishing vs Smart Publish has no affect
The site is correct when viewing the CM version
I'd love to hear anyone's thoughts or questions that might steer me in the right direction.
We finally figured out this issue with some solid help from Sitecore support.
The pages that were "misbehaving" used the Lucene index to locate the Sitecore item and then display information from the item. In our case, the Lucene index was not being updated when the item was published.
Sitecore recommended configuring the HistoryEngine for the web databases on both CD and CM. That fixed the issue.
<Engines.HistoryEngine.Storage>
<obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">
<param connectionStringName="$(id)" />
<EntryLifeTime>30.00:00:00</EntryLifeTime>
</obj>
</Engines.HistoryEngine.Storage>
<Engines.HistoryEngine.SaveDotNetCallStack>false</Engines.HistoryEngine.SaveDotNetCallStack>
We still have a couple things we can't explain and Sitecore couldn't either
How was this working for other sites on the same instance in the past? What caused the issue to start now?
Why were the pages displaying some of the items' content? Where was that coming from?
Now that I know the fix, I'll have to dig in some more to see if I can figure out these questions.
Hopefully this steers someone else in the right direction.
Related
My question is this. I am using OBIEE 12c and recently I changed the .rpd file in offline mode and then uploaded it to the server. However I dont see my changes there.
Interesting is the fact that when I open the .rpd in online mode in Admin tool, which shows the current rpd in OBIEE, I see my changes. I tried editing in online or offline modes, changed the names of rpds, restarted the server, but nothing helped. What could be the reason?
EDIT.. It was my fault partially. I was making changes in BMM layer and I was pretty sure that my changes will be automatically updated in Presentation layer(it was when I checked with several aggregations), however in this case, my changes did not reflected in Presentation layer. Why is like this?
P.S. I was modifying hierarchies if important
I was just looking into referencing css files in a theme, that reside in a different database and I was wondering:
Could I reference a whole theme that resides in a different database as well with "extend"?
The reason behind that is: Would it possible to keep themes in one central database that can be used by all kinds of applications and therefore, if there should ever be changes to the themes, they only have to be changed in one location and not in every application.
Thank you for your responses in advance.
no I don't think this is possible (happy to be wrong if someone else knows it is?)
to keep all your theme files in a central spot, an XspLibrary in an OSGi plugin is a good solution, however it is a steep learning curve if you haven't done this before. The benefit is once you know this technique it opens the door for 'centralizing' other parts of xpages.
you deploy the plugin to each server and each client if using xpinc, and the every nsf can use a theme from that plugin.
there are a few 'getting started with xpages plugins' articles popping up around. check through planetlotus.org (I'll edit this answer later with some links)
once you know how to do an XspLibrary, you can then download the source code of the bootstrap4xpages project on OpenNTF to see how they are serving up their theme from a plugin.
it relies on the Extension library though so if you don't use the exit lib you could reverse engineer the necessary parts of that project too!
this bootstrap project was set up by Phillipe Riand who was the chief architect of XPages, so it should be a good example!
I am halfway through creating a video series on doing a theme from a plugin but have temporarily lost motivation :(. I might finish it sometime this year, if I do I will post a link to it on this answer. in the meantime I am happy to answer any questions you have about it if you want to give it a go.
otherwise, a quick and dirty solution would be put the theme files / CSS / images directly on the file system of the domino server, where the other theme files are. 'Mastering XPages' might have some advice about this but I don't have it with me right now :)
I think the short answer is you won't be able to load just a theme from a different database.
Each NSF has it's own JVM, sitting on top of the server JVM. So you can extend a theme that's sitting on the server, but not one in another NSF.
XPages Single Copy Design loads a theme from a different NSF by effectively loading the template's JVM. So it's the theme, but also all other design elements.
Jesse Gallagher's done some work in OpenNTF Domino API to allow you to load an XPage or Custom Control from another database, but I'm not sure if that would work for a theme.
If you want to design once and use in many, you can add the theme to the server itself. Looks for the OneUI elements to see where you need to store it (or it may be mentioned in Mastering XPages). You can only nest themes to five levels, but you should be fine.
Our production Liferay instance absolutely refuses to deploy my latest theme. Something is preventing it from displaying my latest CSS changes. Unfortunately, there are NO log errors and no Firebug Console errors, so it's been a real headache to diagnose. I just get a really ugly plain page with links and no styles applied.
I have tried everything I can think of to fix this.
Undeploy/redeploy theme
restart the Glassfish container
use Liferay Server Administration page to "Clear content cached across this JVM", "Clear database cache", "Verify Database plugins", etc.
undeploy, restart, redeploy
undeploy, delete leftover files/folders pertaining to the theme in 'applications' folder, restart container, redeploy
clear my browser cache
try a different browser
many more combinations of the above. You get the idea.
Last night I reached the boiling point because my theme deployed and displayed in our test environments without issue, but didn't work in production. The only thing that was different is that I wasn't using
include-and-override=portal-developer.properties
in my portal-ext.properties file.
I took a gamble and added this line to my production portal-ext.properties and restarted the production server. My theme now displays without a problem.
The file portal-developer.properties only appears to contain the following properties:
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=false
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.etag.ETagFilter=false
com.liferay.portal.servlet.filters.header.HeaderFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
So, finally, my question is, am I merely trading a slight performance boost for a massively easier deployment experience?
Or are there more serious concerns to loading this file in a production environment?
Thanks in advance for the input!
Ben
You'll get a really bad performance with that portal-ext.properties. That configuration is only intended to be used in development environments.
If you delete the css/.sass_cache directory on your deployed theme you'll see your css changes and you'll be able to use a different portal-ext.properties on production environment.
http://issues.liferay.com/browse/LPS-26939
Regards
I'm a total newbie with Joomla.
I'm the new man in charge of a website and they want a full redesign.
I have already downloaded everything by ftp into my WampServer and exported the BD.
I changed the configuration.php to point my new BD.
I could access the web but I got lots of Deprecated Errors so I turned off the display_errors in the php.ini
Now I can finally see te content of the web but with no templates and no style.
Any idea what's happening?
(I'm not sure what version of Joomla it was working with.)
Well, the first thing I would do is wipe out what you have moved. Then go download and install Akeeba backup. Take a full site backup, then use that to install on localhost. Doing this will make your life a lot easier when it comes to moving the site easily. If the site has issues after moving it this way, then you can pretty much bet it's a server configuration issue and not a Joomla issue.
Next thing you need to do is determine what version of Joomla you have. The 1.5.x series should have the version in the admin in the top right. The 1.6/1.7/2.5 series will have it in the admin in the footer. You can probably check the source on the front end and it will tell you in the meta generator tag. Unless you are on 2.5.2, then you will want to start planning for a migration to the newest version. 1.5 reaches end of life next month and 1.6/1.7 are no longer supported.
So, we had the hosting service set up a dev site with the intentions to then upgrade our live site once that was done. After a ton of back and forth the hosting service bailed on us, and we're left with an updated dev site and not much of a clue on how to update the live site.
While I'm not asking for a foolproof way of updating the live site, I do need something that won't impact sales by being down....or something that won't be a problem to roll back on in case there's issues.
any guidance / tutorials would be a big help. when I set up our original site we weren't live yet, so I could grind away without losing $$$. That's not the case now.
Thanks!
There are two things that happen for upgrades: new functionality from the updated / additional files themselves, and database upgrades which are triggered by each module's version.
Above all, it may be advisable to find a freelancer or shop with a good Magento track record and experience in 1.3 to >= 1.4 upgrades. They should be able to set you up for the clearest upgrade path moving forward. That said, here's a procedure:
Backup database and filesystem.
Perhaps, make another backup.
Create your own dev environment from this backup: install files, duplicate database, change the db settings in app/etc/local.xml. You likely will need only to change the base_url settings in the core_config_data table: SELECT * FROM core_config_data WHERE path LIKE %base_url).
Check the big core files: Diff your app/code/core/, js/, lib/* files with a known-good copy of the 1.3.2.4 or 1.3.3 (there is no 1.3.4) - check Mage::getVersion(). Any changes will need to be accounted for. And slap whoever changed them :-)
Once you've verified that you have a healthy core / fixed your core, you are ready to test the upgrade. Simply copy the files from 1.5.1 over.
Make sure that you have set a substantial timeout if you have lots of orders.
If you have issues with this upgrade, you may opt to step through versions. Particularly, you can go from 1.3.2.4 to 1.4.0.0 to 1.4.2.0 to 1.5.1.0. At the very least, this might help you spot where along the upgrade sequence things are going to pot.
Also, you will need to fix your templates. Between 1.3 and 1.4 Magento implemented a base design package and default theme; other themes should build from this. You'll almost certainly need to merge your changes from your layout templates (under template/page/; 1column.phtml, etc.).