Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Updating JournalArticles programmatically
Hello, we're using Liferay 6.2 SP17 and creating articles programmatically with this API call
Later we're trying to update article's content programmatically with this call
While debugging, the content property of the updatedArticle variable shows the new content. In the database a new minorversion is created with the correct content. However when we open the article, we can see the new versionnumber but the content is the old one. Why are we presented with the old content?
Thanks, Bernd
JournalArticle newArticle = JournalArticleLocalServiceUtil.addArticle(userId, groupId, folderId, titleMap, descMap, content, structureKey, templateKey, sc);Later we're trying to update article's content programmatically with this call
JournalArticle updatedArticle = JournalArticleLocalServiceUtil.updateArticle(userId, groupId, newArticle.getFolderId(), newArticle.getArticleId(), newArticle.getVersion(), newArticle.getTitleMap(), newArticle.getDescriptionMap(), newContent, newArticle.getLayoutUuid(), sc);While debugging, the content property of the updatedArticle variable shows the new content. In the database a new minorversion is created with the correct content. However when we open the article, we can see the new versionnumber but the content is the old one. Why are we presented with the old content?
Thanks, Bernd
I'm trying to make this code a bit more readable by introducing line breaks
The two easiest points (please check):
It might be something less (or even more) obvious, but these are the quick-to-check points, assuming that you following the debugger closely, would have caught the easiest cases.
bernd kopinits:
JournalArticle newArticle = JournalArticleLocalServiceUtil.addArticle( userId, groupId, folderId, titleMap, descMap, content, structureKey, templateKey, sc);
Later we're trying to update article's content programmatically with this callJournalArticle updatedArticle = JournalArticleLocalServiceUtil.updateArticle( userId, groupId, newArticle.getFolderId(), newArticle.getArticleId(), newArticle.getVersion(), newArticle.getTitleMap(), newArticle.getDescriptionMap(), newContent, newArticle.getLayoutUuid(), sc);
While debugging, the content property of the updatedArticle variable shows the new content. In the database a new minorversion is created with the correct content. However when we open the article, we can see the new versionnumber but the content is the old one. Why are we presented with the old content?
The two easiest points (please check):
- Validate the interface if you haven't exchanged any ids
- The new content should be XML and might have multiple languages. You might only update one language version
- Are you running a cluster, update it on one machine, then access it on the other? In that case this points to a flawed cluster setup
It might be something less (or even more) obvious, but these are the quick-to-check points, assuming that you following the debugger closely, would have caught the easiest cases.
- Validate the interface if you haven't exchanged any ids
Sorry, I'm not sure what you mean by that. - The new content should be XML and might have multiple languages. You might only update one language version
the content before the update looks like<!--?xml version="1.0"?--> <root available-locales="de_DE" default-locale="de_DE"> <static-content language-id="de_DE">hello there</static-content> </root>
the content after the update<!--?xml version="1.0"?--> <root available-locales="de_DE" default-locale="de_DE"> <static-content language-id="de_DE">hello today</static-content> </root>
all that has changed is the string inside of the cdata. - Are you running a cluster, update it on one machine, then access it on the other? In that case this points to a flawed cluster setup
the process is running an my local dev client, so no clustering.
bernd kopinits:
- Validate the interface if you haven't exchanged any ids
Sorry, I'm not sure what you mean by that.
I meant: Double-Check that you didn't exchange some parameters - e.g. the different IDs you provide etc. This is one of the easy to miss problems. Look up the interface, be 200% sure that everything is in the right order.
As I said above: Let's start with what's easy to rule out. Sorry, if this all sounds trivial - everything you write sounds like it should work. Seems reasonable to hunt for the easily missed simple things first...
Does deleting the caches in the service administration help? (Or a restart)
Also, please check the database for differences between the new entry and the old one. e.g. a status might be set.
Also, please check the database for differences between the new entry and the old one. e.g. a status might be set.
Community
Company
Feedback