difference between "content" and "features" (and "description") ?

[cccs-ip]

In our 'Project' records, e.g. WBN-BFS ESHIA, there is a field called "content" and one called "features". What is the difference between these fields? Also, how would either one differ from the metadata "description" field?

[pwhipp]

The content is the main description of the Project. All richtext displayable objects (things that can have their own web page with a main block of 'content') have a main field called content.

features is a separate text field which was separate in the original data.

Currently the project_detail template is displaying the features under the summary profile as markdown. This field is not a richtext field so, while this works fine, it is not ideal. The intention was that content would be used here.

If you need features as markdown in admin etc. we need to change the field type in the model.

Lastly, to add to the confusion. The metadata description is the page header description when the project is presented as a single page. It is primarily supplied for SEO. I've hidden this field to reduce confusion.

I can change the type of features and add it to the template or remove it/combine it with content as desired.

For some reason almost all of the project.features equal their contents. Shall I delete the features field?

[cccs-ip]

Thanks, Paul. We can merge 'feature' and 'content'. Is there a way to ensure that we don't lose information as we do this (and yet not risk duplication)?

I would like this field to be markdown.

Btw. We might want to merge in min's latest before making this change.

[pwhipp]

There is now just a 'content' field which is in markdown format.

I've appended the features data where there was different data in the features field. Some of this data was similar but with minor differences (because of this confusion) so a review of the project content fields is necessary before this issue can be closed.

I could have given the 'content' field a distinctive verbose name but I prefer the consistency of all displayables having a 'content' field as their main block of textual content. In essence, a displayable will always have a title (and a _meta_title), some content and a slug (which is normally a url friendly unique version of the title).

FYI:

Research -

In [5]: projects = [p for p in pm.Project.objects.all() if p.features and p.content != p.features]

In [6]: len(projects)
Out[6]: 39

In [7]: projects[0].features
Out[7]: u'In the lead-up to their periodic review of all their environmental and social safeguard policies, the European Bank for Reconstruction and Development chose to conduct reviews of all the multilateral development bank policies dealing with vulnerable groups with an eye towards recommendations for their policy rewrite.\r\n\r\nCCCS supported the Environment Department of EBRD in finalizing its draft of it Indigenous Peoples policy requirements by:\r\n\r\n* conducting a survey of policies safeguarding vulnerable groups that were in place at major multilateral development banks and among major private sector companies\r\n* reviewing state level Indigenous Peoples legislation and recommending amendments to the draft EBRD policy\r\n* organizing and facilitating a day\u2019s workshop with IP and relevant stakeholders to discuss the draft policy\r\n'

In [8]: projects[0].content
Out[8]: u'RETA 6285: Strengthening Country Safeguard Systems'

Added a datamigration to combine the feature/content.

(cccs)~/wk/cccs/core $ django migrate projects
Running migrations for projects:
 - Migrating forwards to 0012_append_features_to_content.
 > projects:0012_append_features_to_content
 - Loading initial data for projects.
Installed 0 object(s) from 0 fixture(s)

Tested.

Added a migration to drop the features (and related translation) fields.

Tested.

This will be updated in production on the next deployment

[cccs-ip]

Thanks. I look forward to getting materials into production so that we can begin working our way through them.