5.1 Bug? export/import of community (loosing article ids in content portle)

[Boris Reichel, modificado hace 15 años.]

Hallo,

I tried to export a community and import it on a different machine. Using Liferay 5.1.

As it seems it works for the page structure and the page contents ... but not for the contents of the journal content portlet.
As it seems on import the articles get a new id but the journal content portlet sitll uses the original id which leads to an error, that the article is not present.

I tried the export/import with standard selections (what to export/import) but it does not work. The problem occures as well if trying to do the export/import inside a single Liferay 5.1 instance.

Did I missunderstud something? ... or do I have to do a DB export/import to transfer the structure and content of a community into a other liferay instance?

Any hints wellcome!

Thanks, Boris

[Allwyn Fernandes, modificado hace 15 años.]

We've seen the same problem with 5.0.1.

The work-around we're using is to create the articles and tag them with a title/identifier. The tags are preserved across an import/export.

Then, we can use the Asset Publisher (which selects articles by the tag) rather than the Journal Content portlet (which selects articles by the non-preserved articleId).

I hope this helps...

[Boris Reichel, modificado hace 15 años.]

Thanks for the hint ... sounds interesting. I will try it.

Does the workaround perform well? I would suspect, that searching for tags is significant slower than accessing an article by its id ...

I found some property in portal.properties which sound to help:

##
## Journal Portlet
##

#
# Set this to true if article ids should always be autogenerated.
#
journal.article.force.autogenerate.id=true

Now I can give the articles own ids (just a unique name like the tag) ... which works ... but not the export import ??? Dont know why ... I have to do more analysis.

[Allwyn Fernandes, modificado hace 15 años.]

Boris Reichel:

Does the workaround perform well? I would suspect, that searching for tags is significant slower than accessing an article by its id ...

We haven't noticed any significant slowdown - when there's only one article with a given tag, it's much the same as searching for an ID. If you get different results I'd be interested to know.

Boris Reichel:

#
# Set this to true if article ids should always be autogenerated.
#
journal.article.force.autogenerate.id=true

That looks very interesting... Do you have it set to false on both servers? I should explore that on our end too.

Cheers.

[Boris Reichel, modificado hace 15 años.]

now it works (using the default settings for export/import) ... i don't now what happens before ... i have done the tests on my local server so i have done the false-setting just at the one server.

If you are working with a cluster (my presumption) you must configure all cluster instances the same. This can normaly easy done if you mount the docroot for all servers in your cluster to one directory (the single code base).

cheers, boris

[Ray Augé, modificado hace 15 años.]

This has been thoroughly tested and is being used alot.

Are you sure you chose export options indicating to export Portlet Data?
You should not be losing references to Journal Articles even if the id's
change, we maintain the relationship.

[Boris Reichel, modificado hace 15 años.]

I have done the export/import with the standard options, started from the community portlet ... now it works like expected. I don't know, what I have done different last time that it hasn't workt.

Thanks for your help.

[Allwyn Fernandes, modificado hace 15 años.]

Ray Augé:

This has been thoroughly tested and is being used alot.

Are you sure you chose export options indicating to export Portlet Data?
You should not be losing references to Journal Articles even if the id's
change, we maintain the relationship.

I assumed it must be a well used feature, but we're definitely seeing this happen. I'm doing export and import with all the default options set in the manage pages portlet; these definitely include the "Data" option being selected.

Notably, all the content does get created, but in many (not all) cases, the links are broken. Articles are created with new IDs, and the old Journal Content portlets simply display

Journal Content:

Select an existing article or add an article to be displayed in this portlet.

16249 is expired, is not approved, does not have any content, or no longer exists.

[Juanjo Hernández Cánovas, modificado hace 15 años.]

I have the same problem, using Liferay 5.0.1.

We have two environments, one for development and the production one. We want to create the theme and the site in the development environment, export it and import in production. But the relation between the journal content id and the article is broken because the journal content still uses the original id.

Any solution already? Exist any workaround working well? Using tags or the portal-ext.properties configuration works?

Thanks in advance,

Juanjo

[Boris Reichel, modificado hace 15 años.]

Hi Juanjo,

did you tried allready 5.1.x?

At the moment we are running on 5.1.x an die Export/Import is working well ...

To do the Export/Import i use only the Community-Administration-Portlet ... not via the manage-pages function inside a community ... maybe you get in trouble if you export/import a community site while using it???

hope it helps, Boris

[Juanjo Hernández Cánovas, modificado hace 15 años.]

Thanks Boris,

Your recommendation is for versión 5.1, isn't it?

Something for 5.0.x?

Thanks,

Juanjo

[Boris Reichel, modificado hace 15 años.]

Hi Juanjo,

yes, we use the 5.1.1 which works (at the moment, and at my machine ;-) ... about 5.0 i have no suggestions). As written bevore i had problems which are no more existent ... i dont now how or why ... maybe i have done the export in a "wrong" way. Now i do all Page-Manipulations only via the community portlet.

cheers, Boris

[Dana Oredson, modificado hace 14 años.]

TagsAssets are not getting correctly hooked up again.

For instance, when I configure AssetPublisher in Manual mode, add articles and/or documents, AssetPublisher points at a TagsAsset. That fine in a standalone environment.

Now, export your community. AssetPublisher's preferences are exported as-is, so on the new server, where you are importing your LAR file, the TagsAsset.assetids have new values, so AssetPublisher has broken information and just prints stacktraces in the log files.

I'm working on a workaround that uses an AssetPublisherPortletDataHandler and grabs the UUID of the document pointed to by the TagsAsset. Then on import, looking up the Document with the UUID and Groupid, find the TagsAsset that points to THAT. Then update the PortletPreferences to point to that assetid.

That works for documents that are point to by the AssetPublisher. However, I'm having trouble with JournalArticles pointed to by the AssetPublisher. The articles are not getting pushed to live if they are only referenced by the AssetPublisher. If I publish to live from a staging environment, the AP can still find the article, but it is an article in the STAGING environment. NOT the live/approved article (because assetpublisher is finding it by assetid, which is unique to the liferay instance, not to the group (BAD).

It seems to me that export or publishing to live of a community should do the same thing: Always publish all approved articles, irrespective of whether they are referenced by a portlet. Because articles can always be pulled in by an asset publisher, or included via the journal-article tag, etc.

Not sure how to fix the broken manual setting for journalarticles (we're using it for a manual news and alerts - we could use something else, of course). The alerts portlet is broken because it's only showing messages if you're logged in, which is crap. I need Guest to be able to see it (there seems to be a configuration to do that, but it doesn't work).