I'm importing content to Plone using a transmogrifier pipeline and I need to set the dates (creation, effective and modification) on the items when creating them.
The fields I'm trying to update are: creation_date, effective_date and modification_date and, for Dexterity-based content types, I can confirm that the updater works only on fields listed on the schema, so the ones stated before are just ignored.
What's the right way of accomplish this task? Do I have to write another pipeline section of is there something available in another package?
Related
I am working with the commerce module to create an online store. I am modifying the products .install file to create a content type (as I have been told this is required) and as part of that content type, I need to create lots of fields. The list will be around 50-60 different pieces of information.
Ideally I would like to store these in a single table with the productID at the beginning and all the other information along, but this doesn't seem to be the case; all the fields are stored in different tables.
I noticed that the "Address" module that is also used with commerce creates a field-type that has about 15 different values all stored in the same box. How is this possible? I noticed that if I set the cardinality up to 5 for example, it creates different rows. I just want a table with the following:
ID - value1 - value2 - value3 etc etc.
I also don't need any modules/extensions as this all needs to be written in the files. I also don't think that changing to the mongoDB ( I think ) is an option, so what are my options in this situation?
That's not how the Drupal field system works I'm afraid, one field == one table (well actually 2 tables if you include the revision table for each field).
The Address module uses hook_field_schema() to define several columns for that particular field (have a look in address.install and you'll see what I mean).
So if you want to put everything in one table you'll simply have to define your own field type (see the examples module, specifically field_example for help with that).
Bear in mind though that the number of columns you define in hook_field_schema() will be static once the module is installed, and the only way you're going to be able to increase/decrease it is with an _update hook for your custom module.
Also, if you're hacking at files that are included in the Commerce module...stop!: Commerce is still very much in it's infancy and you will likely have to update it soon...once you've done that your code changes will be gone and there's a good chance your site will be in an inconsistent state.
The whole point to Drupal is that everything is hooked/farmed out so that it can be altered by other parts of the system. There's nothing you can change in product.install that can't be done by implementing a Drupal hook in another module.
If you're unsure, post another question detailing what you're trying to accomplish by directly editing a contrib module file and one of the Drupal gurus on SO will point you in the right direction :-)
EDIT
Just to say I've been working with Ubercart in Drupal 7 for quite some time now and find it a very, very good solution (a lot of Commerce contributed modules are still in dev/alpha/beta; this is less so for Ubercart contributed modules). It might be worth a look.
Some more info
I think you've basically got two options here but either way you'll need to create a custom module (excellent set of instructions here).
Option 1: Create a custom field
If you're a Drupal coding beginner I'd suggest this is probably the easiest way to accomplish what you want, but it's still not totally straight forward. Grab the field_example module from the Drupal Examples module link above and have a look in the .install file, specifically the field_example_field_schema() function. That defines the columns that will be in the table for that field. Then have a look in field_example.module...pretty much every function that's commented with Implements hook_x is one that you're going to want to copy into your module and tweak for your own needs.
I think this will be easier because Drupal will handle the table/form field creation for you
so you don't have to mess with the database, schema or form APIs.
Option 2: Create a custom module
This option involves implementing your own table (like you suggest in your comment) where the primary key would be the entity ID of the product and would also contain all of your custom columns. (See the Schema API documentation for help with this).
Then you'd implement hook_form_alter() to add the form fields necessary for a user to input the data, and then implement hook_node_insert() and hook_node_update() to persist this data to your database table. It's quite hard to go into any more detail without actually writing code and it's quite a bit of code!
Hope that helps, sorry I can't be any more specific but it's not easy without knowing all the ins and outs of the situation
Background: The working copy behaviour is not really supported for container types as it leads to problems copying all the children of that folder. We're working round that by using child data types for our container types: Almost all data about the container is stored in a data object that is a child object of that container and its default view. We exclude the data objects from listings and search.
Problem: This leads to an inconsistency where currently we have to give the dublin core behaviour to the container type, not the data type, because all the core Plone code expects description, effective date etc to be there. This is slightly confusing for our Plone editors as they have two places to edit data about the container. This data can also only be edited on the live version, rather than a checked out working copy.
What I'd like to be able to do is:
delegate any requests for dublin core data from the container to the child data object (no idea where to start on this)
on saving the container it will use the child data dublin core data for its meta data in the catalog (this should just work if the first part is working)
on saving the child data it will reindex its parent object to update its meta data (I was planning on registering an event to achieve this)
Please can someone provide me with some pointers on how to achieve this first part?
I think you have two options here:
Make your own metadata behavior that looks up metadata on the data object.
Simply update the parent's metadata in an event handler when the data object is modified.
Given you'll need the event handler to force the parent reindex anyway, I'd probably go with the simple copying of metadata approach.
I'm building a site with OpenAtrium Drupal installation profile. I want to have multiple content types of "cases" that can be tracked together (obviously they would all share the basic case fields). I'm wondering what the best way to approach this is. Should I make an override module that overrides atrium_casetracker? Should I make a completely new feature?
I've been in this position before. Here's what I recommend.
Create your new feature. Possibly even one new feature per case type if each case has a lot of associated configuration and customization code.
Modify the casetracker_case_node_types variable so your content type is recognized by casetracker as being a case type. You need to do this before creating nodes of your new case type, otherwise you will have migration complexity. (See http://drupal.org/node/734542 to make that better.) **For compatibility with OpenAtrium's Atrium Casetracker feature, modify this variable with hook_strongarm_alter() to avoid creating a feature that conflicts with Atrium Casetracker.
Be sure when exporting your content type that all variables and node options are properly configured and exported with your content type, such as the atrium updates variable and the og usage variable.
If you need to change the default case, you can export CCK fields and other configuration related to that node type in your new feature.
If you have questions on this, please comment and I will update my answer to clarify further.
Collections provide an option to select columns to be display within the table view of collection.
We are extending most content-types with two fields using archetypes.schemaextender: teaser image and teaser text.
Is there a sane way to extend the list of available table columns?
Is there a way to display the teaser text and teaser image inside the table view of the collection with out further customization? Is the logic of the table view flexible enough in order to support a schema extension?
In the control panel -> collections ( typically /portal_atct/atct_manageTopicIndex) you can define every metadata you need. Collections depends on portal_catalog metadata and indexes, so you've to add your custom fields there. Use GenericSetup in your module profile to tell ZCatalog to create the new indexes, or create them by hand. In the former case, beware that reinstalling the module could wipe out the new created indexes ( http://maurits.vanrees.org/weblog/archive/2009/12/catalog ).
You might want to take a look at collective.formcriteria. I haven't polished it nearly enough and installing it can get you in some uninstall trouble so don't install it without first backing everything up. That said, it gives you more than enough rope to do what you want using column expressions. Of course this is also more than enough rope to hang yourself with.
I am uploading several files to Alfresco repsitory via webdav. The batch process works fine, but after the upload, all dates in the repository are changed to current date.
How can I make it keep and show the original file dates (creation and modified) ?
Thanks.
You can leverage metadata extractors. The main purpose is to extract metadata from binary files during upload. There are lots of built-in metadata extractors, just look for implementers of interface org.alfresco.repo.content.metadata.MetadataExtracter. There are different extractors that can extract creation date and set it as cm:created on Alfresco node.
You can enable metadata extraction by applying it as a rule on a space, look for action named Extract Common Metadata in the actions drop-down-box while creating the rule.
I don't believe it's possible without the importing code explicitly turning off the default behaviour of the "cm:auditable" policy, and I suspect the WebDAV driver doesn't do this (since it has no way of knowing whether that's appropriate or not - there are cases where forcing the creation and modification dates to today is the correct thing to do).
This behaviour is discussed in some detail here - it might be worth evaluating whether the bulk filesystem import tool is a more appropriate way to import the content into Alfresco, particularly since it can preserve the creation and modification dates if you tell it to (i.e. by specifying the values of those properties).