I have an archetype content type that previously was not folderish. Now I have set it as folderish. What attribute or properties need to be changed so that any data created before can be migrated?
I have read the following documents:
Generic Setup Upgrade Steps
Converting one Content Type into another
I followed the above tutorial on upgrade steps but I do not know which attribute or properties to change.
You could use Products.contentmigration. See it's doc to find out how to use it, it shouldn't be too difficult: just define your CustomQueryWalker and the mapping between your two content types. In order to find out what field you have to map, just put a pdb somewhere in the content's view and inspect the content schema.
similar question here: Migrating from (now obsolete) custom ATImage content type
i stumbled accross the same issue when trying to migrate non-folderish types to folderish ones based on: http://pypi.python.org/pypi/collective.folderishtypes
that helped: on a context to convert, call ##migrate-btrees view [1] to initialize the btree structure [2]. I assume your new Archetype content is plone.app.folder based.
[1] defined in: plone.app.folder.migration.BTreeMigrationView.
[2] Main work is done by: Products.BtreeFolder2.BTreeFolder2Base._initBtrees.
Related
In Alfresco, if a type name is removed/changed all nodes of that type will disappears but still exists.
Using alfresco 5.0.c I've added some custom types:
eg:
<type name="my:test">
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
now i deploy it and create a folder of this type (a simple folder, then change type)
Now i edit the type like this:
<type name="my:test2"> <!-- from my:test to my:test2 -->
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
Deploying this: any "my:test" folder will disappear, but, if I try to create another folder with the same name I get an error becouse the node still exists.
These nodes will not be not even listed within the folder child:
print(document.getChildren());
How can I recover (if possible using the the javascript console) all the "broken" nodes and be able to change the type?
A little preface: as widely stated by Alfresco, if you want to change your custom content model you should change it only incrementally.
This means that you can't remove any properties, types or aspect at definition level of the model, you only can add new definitions in the content model of Alfresco.
So it is a very bad practice to change types "on the fly".
A good practice is to always start with a model as small as you can and then add features as long as you need them.
In your case you should have deleted all nodes referencing my:test type BEFORE changing the model and then safely remove it and finally you should have performed a full reindex. This could be the reason why the repository tells you that the folder exists even if you cannot see it anymore.
As far as I know it is not possible to delete this inconsistent nodes through the console, so my advice is to perform a full reindex. If the issues come up again then you should consider to start again from scratch.
Another approach next time is to add the new type and programmatically hide the older one.
I have notices that types created with paster on the file system can be changed using the TTW editor.
When I reinstall the product the TTW changes persist, and the model file seems to be ignored. How can I discard these changes? Is there a guide to the relationship between web changes and file system changes?
A content type's entry in the portal_types tool has 3 properties related to where the model is loaded from. They are checked in this order:
model_source: The XML model, inline
model_file: Path to a file which contains the XML model
schema: Dotted path to a Python schema
My guess is that you need to make your filesystem product's installation profile explicitly empty model_source, so that it won't take precedence over model_file and schema.
We had a whole collection of Plone 3 sites with a custom Image type
subclassed from ATImage. This allowed us to add an extra image scaling to the
standard list ("'logo':(454, 58)", used by our theme package).
While this still works in Plone 4, it isn't really the correct approach now that
plone.app.imaging is part of the standard toolkit. That can define custom scales on
the fly.
It looks like I can enable plone.app.imaging on any type subclassed
from ATImage by simply setting "sizes = None" for the collection of custom
scales on the type. I am however then left with a redundant subclass of ATImage.
Looking long term, it would be useful to replace all of our existing "FalconImage"
content items (hundreds in total) with standard "Image" content items.
A brief experiment on a test site reveals that if I just walk through the document
tree updating the portal_type attribute from "FalconImage" to "Image" then
the content behaves as an "Image": each object suddenly acquires a
Transform tab and all of the scales defined by ##imaging-controlpanel.
I am sure that there would be fallout from such a brute force approach.
Is there a recommended approach for transforming one type into another?
(I'm happy to add source for our custom ATImage type if anyone thinks that
it is relevant. It is really just a very minimal tweak of ATImage, with a
different collection of sizes on the ImageField)
Yes, there is a recommended approach:
http://pypi.python.org/pypi/Products.contentmigration
The only thing that you have to do is to write a custom migration from FalconImage to Image.
Bye,
Giacomo
You need to use Products.contentmigration but the docs there are no place to start. Use the docs at plone.org for a step-by-step on migrating content.
Thanks to Giacomo and Ross for the pointers.
Just in case it is useful to others, my migration code ended up looking like the following:
from Products.contentmigration.walker import CustomQueryWalker
from Products.contentmigration.archetypes import InplaceATItemMigrator
class FalconImageMigrator(InplaceATItemMigrator):
walker = CustomQueryWalker
src_meta_type = "FalconImage"
src_portal_type = "FalconImage"
dst_meta_type = "ATBlob"
dst_portal_type = "Image"
# Following stolen from plone.app.blob.migrations, ATImageToBlobImageMigrator
# migrate all fields except 'image', which needs special handling...
fields_map = {
'image': None,
}
def migrate_data(self):
self.new.getField('image').getMutator(self.new)(self.old)
# ATFileToBlobMigrator reindexes certain fields. Otherwise we
# need to clear and rebuild the entire catalog.
def last_migrate_reindex(self):
self.new.reindexObject(idxs=['object_provides', 'portal_type',
'Type', 'UID'])
migrator = FalconImageMigrator
walker = migrator.walker(portal, FalconImageMigrator)
walker.go()
print walker.getOutput()
Complications:
Image is a little odd as a destination type, as data gets migrated into the blob store.
We need to update the catalog so that "resolveuid/UID" links generated by TinyMCE
continue to work. last_migrate_reindex() method on Migrator class should be faster than clearing and rebuilding the entire catalog from scratch.
How do I prevent a specific content type from appearing in collections (smart folders) site wide in Plone 3? I've looked for relevant options in portal_types and the types and search control panel (turning off the content type for searching doesn't seem to have an effect on collections).
Specific situation: I recently installed plone.app.discussion on a Plone 3.3.5 installation and now comments appear in all the collections. We want to remove them from the collections.
Thanks.
Portal Types criterion is based on plone.app.vocabularies.ReallyUserFriendlyTypes, a vocabulary factory defined in http://svn.plone.org/svn/plone/plone.app.vocabularies/trunk/plone/app/vocabularies/types.py.
If you patch BAD_TYPES by adding discussion comments you'll exclude them from Collections, but you'll also hide them from anywhere this vocabulary factory is used. As far as I know they are also used in contentrules and search control panel.
You can patch BAD_TYPES by adding these lines into __init__.py file of a custom package:
def initialize(context):
"""Initializer called when used as a Zope 2 product."""
from plone.app.vocabularies import types
types.BAD_TYPES = types.BAD_TYPES + ('Discussion Item',)
If you don't have too many collections, the simplest solution might be to add criteria to exclude comments. You can easily get a list of all your collections:
http://your-site/search?portal_type%3Alist=Topic
If you have a lot of collections, you might need to write some custom code to do this. It doesn't have to be a product or anything serious, just some code you can run to add an 'exclude comments' criteria to existing collections. I would start by looking around line 507 of http://svn.plone.org/svn/collective/Products.ATContentTypes/branches/1.3/Products/ATContentTypes/tests/test_criteria.py
You can add criteria to your collections stating which content types you want to display. You can not (without patching/hacking) choose which to exclude.
I.e collections have can have type whitelilsts not blacklists.
I have created a configuration section designer project to represent nodes of a custom section necessary to read and save from my web application. I am able to successfully create instances of the configuration elements and collections, however when I save the configuration using the referenced System.Configuration.Configuration object and issuing save, the elements get merged into their parents as attributes. An example of the issue is outlined below:
After calling the referenced Configuration.save, the output is as follows:
<savedReports xmlns="SavedReportSchema.xsd">
<resultsSets dataViewId="1" id="4203bb88-b0c4-4d57-8708-18e48f0a1d2d">
<selects keyId="1" sortOrder="1" />
</resultsSets>
</savedReports>
As defined in my configuration section designer project (confirmed by the resulting xsd as well) the output should match the following:
<savedReports xmlns="SavedReportSchema.xsd">
<resultsSets>
<savedReport id="1">
<selects>
<select keyId="1" sortOrder="1"/>
</selects>
</savedReport>
</resultsSets>
</savedReports>
Any ideas? The element collection types are set to BasicMapAlternate however when I set them to AddRemoveClearMapAlternate they are not merged but they are prefixed by "add" rather than "select" or "savedReport" causing the validation to be off.
Turns out AddRemoveClearMapAlternate was the option I needed to correct my problem referenced in the question.