In the past I've heard that it can be dangerous to rename the Plone site object(change it's id).
Is renaming dangerous? What are the potential issues when renaming?
The problem seems to be in the references (from http://plone.293351.n2.nabble.com/Renaming-the-Plone-object-via-ZMI-td4428462.html):
I am trying to rename the Plone object via the Zope Management Interface, however as a side effect, all references I have on "reference_catalog" are lost, including LinguaPlone translations, related content and the path criteria from collections.
I am using Plone 3.1.7, and you can reproduce the problem by creating a vanilla Plone object, add some Documents with related content pointing to each other, add a Folder and Collection, and add a path criterion to the collection, pointing to that folder. Check "reference_catalog". After that, rename the portal object and "reference_catalog" will be empty.
Is there any sollution for this problem?"
Which was answered with:
You need to update your catalog, since the plone object's id is the
first element of the path of all your content.
http://plone.org/documentation/error/portal-content-has-gone-missing/
In the thread there are some links to scripts to avoid losing references.
Any reference to an object that is stored as a path will be a problem. As Yuri's answer points out, that includes the paths in catalogs. That's a relatively easy one to deal with, by doing a full rebuild of the catalog. There are other issues that may be harder to find, such as paths within collection criteria and portlet data.
Related
When trying to update a Custom Content Model in Alfresco I decided to upload and activate a new copy and delete the old one. I found out this doesn't work.
So my question is what will happen now and how can I fix this?
What will happen where the two content models are the same?
What will happen where the two content models define the same aspect, but differently?
Does one take precedent over the other?
Would editing the 2 in the properties to be identical get around the problem?
Starting from scratch with this repository is an undesirable option at this time. I'm looking for the simplest solution possible.
It's not simple as that. If you already have some documents or folder associated with a model, you can't delete it without breaking your datas.
Also, Alfresco doesn't support multiple declarations of a model or type or aspect. If it's the case it doesn't start.
The only way you have to upload a new version of your model is by uploading a version containing ONLY added properties, types or aspects. If your new model's version contains modificated or deleted properties, types or aspects, you will have to migrate each node programaticaly.
I have a Plone instance which contains some structures which I need to copy to a new Plone instance (but much more which should not be copied). Those structures are document trees ("books" of Archetypes folders and documents) which use resources (e.g. images and animations, by UID) outside those trees (in a separate structure which of course contains lots of resources not needed by the ones which need to be copied).
I tried already to copy the whole data and delete the unneeded parts, but this takes very (!) long, so I'm looking for a better way.
Thus, the idea is to traverse my little forest of document trees and transfer them and the resources they need (sparsely rebuilding that separate structure) to the new Plone instance. I have full access to both of them.
Is there a suggested way to accomplish this? Or should I export all of them, including the resources structure, and delete all unneeded stuff afterwards?
I found out that each time that I make this type of migration by hand, I make mistakes that force me to do it again.
OTOH, if migration is automated, I can run it, find out what I did wrong, fix the migration, and do it all over again until I am satisfied.
In this context, to automate your migration, I advise you to look at collective.transmogrifrier.
I recommend jsonmigrator - which is a twist on collective.transmogrifier mentioned by Godefroid. See my blog on it here
You can even use it to migrate from Archetypes to Dexterity types (you just need matching fieldnames (and matching types roughly speaking).
Trying to select the resources to import will be tricky though. Perhaps you can find a way to iterate through your document trees & "touch" (in a unix sense) any resource that you are using. Then copy across only resources whose "timestamp" indicates that they have been touched.
We have a CRM 2011 managed solution that includes some changes to a standard entity (account) - i.e. new form and some extra fields. In most cases, we can install without a problem as the changes are merged. However we have encountered some instances where a client has renamed the Account entity to something else (Company) as an unmanaged chage (including view names) and our solution changes the entity name and view changes back to 'Account' when installed, based on the 'last one wins' rule.
My question is, is it possible to protect un-managed changes, so that we do not overwrite un-merged changes? i.e. similar to Managed Properties?
Any suggestions would be most appreciated.
Unfortunately, I don't think this is possible although maybe I don't fully understand what you are aiming to do. When you export a solution it will save a snapshot of all the included components. When you reimport, it should set all of the included components as they were when you exported them. If you exported the account entity with a customized name, what sort of logic would you want in place to disallow that change to be imported?
If anyone else has a solution to this, I'd be glad to see it but I haven't come across one yet.
I'm creating a web application and I just want to know how to think about Drupal's db coming from an MVC background.
I have tables to represent people's data such as SSN, First Name, Last Name, Zip Code, Address, Language, Location. Now on the front end I want to create a form to populate this information for a bunch of subjects (people). I have my database normalized so the Zip Code has its own table (with a foreign key link to the person table). The "person" table has stuff such as First Name, Last Name, Address etc... and the "language" table will have the different language abbreviations (again with a foreign key back to the person table).
I would like to know how to move something like this to drupal's schema. I know I could create my own tables and link them back to the "node" table and then I guess build my forms to accept user input...but is this the suggested way to do it? I was looking at webform, but it seems this should be used for simpler forms where the database isn't normalized and everything is just stored in one large table. I'm not sure, but I would definitely love to hear what you guys think...and if you could point me to some resources that'd be great.
Drupal is flexible enough that you can create whatever tables you want and then write code to link them back to the node table. However doing this will mean that you end up with a lot of code which is very specific to your schema, and is not very interoperable with other Drupal modules.
You will find that you get on better with Drupal if you mostly do things the Drupal way. And only go for a very customized solution where you are doing something which isn't covered by standard Drupal modules.
For example you may find that the profile module fits your needs as far as standard information about people goes. The location module (specifically user location) will cover users addresses. By using these modules you are more likely to find other modules which work with them in future and overall you will find you have less code to write.
One thing you may find useful is the migrate module for getting your existing data into Drupal.
It sounds like you're just storing information and the subjects (people) won't be users of the Drupal site.
Leveraging the node and CCK modules to make this happen would remove most of the development work. For example, each of your tables (e.g. Person, Zip Code, Language) could be represented by a content type with a number of fields. The foreign keys would be represented by node reference fields. So the Person content type may have one or more node references to nodes of type, Language.
The migrate module seems well used (626th most popular of 4000+ modules used in at least 10 distinct Drupal sites), but it may be easier to whip up your own migration script, but I'm not familiar with either your situation, your familiarity with Drupal's API, or the migrate module.
Node reference fields display as links to the referenced nodes by default, but can be themed to load and display the referenced node instead (e.g. displaying Language information in a Person node). There's a handy screencast that illustrates how to go about theming node reference fields to load and selectively display the referenced nodes' contents.
Coming from an MVC background you may not like how Drupal stores data in the DB.
Profile module was mentioned, but I find I get more flexibility with Content Profile and CCK combined.
I've written some migration scripts before from Coldfusion to Drupal, and it's not too involved.
We have a content-type built using CCK. One of the fields is a node reference. The node picker is using a view to build the options.
A few days ago, everything was working well.
Today, it looks like all node reference fields using views to populate the selection options are displaying the wrong label. Every single label in the option is ``A'', but the actual node number is correct. The form actually works, just the labels are incorrect.
We have tried just about every combination of edit/save, disable/enable, reboot, clear cache, clone the view, rebuild the view, new view, etc, but we still have a big list of As.
If we create a brand new content type with a brand new node reference field, we get the problem.
Through some backup/restore exercises, we have determined that the problem is actually in the database and not in the code.
We can restore our last good backup, but we will lose a decent amount of work we have put into other parts of the database.
We enabled mysql query logging, and the view is actually being called properly, but we cannot track down where the problem is creeping in after that (unraveling the CCK / Views / Drupal plumbing is a challenge).
The install was build with latest stable versions as of April.
The problems referred to in http://drupal.org/node/624422 is similar, but our code versions include the patches mentioned.
Any ideas would be appreciated. Thanks.
I had a similar problem with using views for node reference, after quite a lot of hair pulling it turned out to be that my caching layer was buggy. I was using memcached, but memcached wasn't truned on on the server. It may be worth checking.
Thanks for the responses. We finally got to the bottom of this.
There was a module that was doing a custom hook_views_post_render() that did a prep_replace to rewrite some output. Unknown to us, there are instances where the $output parameter isn't a string, but an array, and this was causing the problem. One of those instances happens to be when you attach a view to a build a select in CCK.