UCDLIB Collections Post Type

[sbagg]

The plugin will combine ua_collections and manuscripts into a single collection post-type. Data from the existing manuscripts/collections from #18 will be added to the site.

The following diagram describes some of the major components for the implementation, and how in particular new collection entries will be made.

For a new collection post-type ..

1. The user starts a new collection post-type
2. They add an alma record number (or permalink?) and click
3. block will use a special WP-API endpoint to return the PRIMO records as JSON-LD, consistent w/ the metadata as recovered by exlibris open linked data eg. This is to leverage the controller in sils permalink
4. Block will fill in the title, description, extent, etc with record values.
5. User can update any fields
6. When the user saves / updated fields are stored to meta_keys for the record

[sbagg]

@spelkey-ucd We have some questions about this build:

1. Should this be a Collections custom post type with data entry similar to News, possibly with a block pattern used to pre-populate the left section with a template? (see a picture of the green border page layout, our idea is the page would be initially empty but when Fetch is used to searching for a D-###, it would pull the ALMA data from an API we create). We’re hoping the user can just click the + button at the top when logged in and viewing the collections, to quickly create a new Collection post type.
2. Can we make the Title an actual title, and leverage the UI client-side to set the page slug when they search for a D-### id?
3. When saving the page of editor blocks for a particular collection, should we save the meta-key data in the JSON/HTML template or whatever, or should we just have the client/server fetch the data when loading, just in case the meta-key data changes?
4. We’re thinking of just using tags for the various terms we get back from ALMA since they won’t necessarily be categories in our WP.
5. Also how are you going to scaffold out the collections post type or creating an API for the collections post

[qjhart]

Some comments on @sbagg's questions:

• [ ] Reviewing news (which seems closest) our first take on the title/slug issue is that we leave the title as is (eg. Theater Company Data) and just all the user to set the permalink to collection/D-232. We will look to see about setting the permalink when the user data from the alma record based on call_number.
• [ ] Item 3. has to do with where the meta_keys are written. Either the server is in charge on saves, or the page can access the WP API and save the meta_keys directly. My take is maybe the client method is a better general solution, esp in this case where the <view> will need to retrieve that data via the API anyways, unless a special twig does this to the content?

[spelkey-ucd]

So I started scaffolding out the plugin in #37 , some of your questions can be addressed by that.

1. Yes, it is a new post type with a block template. The template will have template_lock => all parameter, so that the user can't delete or move the blocks - just edit what is there. You could put a 'sync' button below the Call number metadata input, which will run your fetch process. You might need additional 'hasBeenEdited' fields for each metadata field, so that the user doesn't accidentally write over any local changes they made when getting updates from ex libris.
2. Yes, that's a good approach. You would do:

   const slug = SelectUtils.editedPostAttribute('slug') || '';
   const { editPost } = useDispatch( 'core/editor', [ slug ] );
   editPost({slug: 'new-slug'}) // from your call number input event listener

   You could also do it on the server side by using the save_post hook

3. Values should be saved as page metadata (editPost) not as block attributes (setAttributes). Although I'm not entirely sure what you are asking, so that might not be relevant.
4. No, tags are an uncontrolled list. There should be a custom taxonomy for manuscript subjects, which is already on sandbox. The terms have to exist before you can associate them with a post.
5. The post type has been scaffolded out on sandbox. I have not done the API but documentation is here.

[qjhart]

@sbagg / @UcDust

Data Workflow

I have updated the collection spreadsheet gdoc to include pointers to the API calls for the primo data. The field is the primo PNX (display record) and the field is the open linked data field that we will be using. Although these all seem to exist in ex-libris open-na store, we will still need to write the WP API extension because the open-na is incomplete.

Here are my suggestions on the minimum conversion, which we can update.

item	required	PRIMO	WP-API / open-na	post_meta	notes
call number	required	.delivery.holding.callNumber	.identifier[@type="calNumber"].value	col_callNumber
title	required	.pnx.display.title	.title	POST.title
date	optional	.pnx.creationdate	.date	col_date
author	optional	.pnx.addata.aucorp	.creator	col_creator
featured image	optional		N/A	User added only, standard POST featured_image
extent	optional	.pnx.display.format	.extent	col_extent
finding aid	optional			(see link)
description	optional	.pnx.display.description	.description	POST.content
history	optional	N/A	N/A	N/A	Not available for us, can add to POST.content
alma record id	optional	N/A	.identifier[@type="alma"].value	col_alma_identifier	This is specific for us
tags	optional	.pnx.display.subject	.subject.label	col_tags	This might have a more standard POST value (Not categories)
links ^1	optional	.delivery.link[linkType:"addlink"]	(Need to Lookup)	col_link	Can be many

^1 I propose we add one col_link per link item but store the URL and Link title together using the standard format, URL title where the first space separates the URL from the title. This makes it easier to maintain.

[qjhart]

regarding @spelkey-ucd comments on item 3. The question is does the client update the post_meta via writes to the WP_API, or do we write them from the server, presumably via the save_post_hook. As I said, I can see reasons for both, ways; the client since then we wouldn't need to save (unused) block attributes to the server, and we have to fetch the metadata via the API on view (or I guess in a TWIG?). I imagine it might be easier to write as a save_post_hook, though.

[UcDust]

@spelkey-ucd @qjhart @sbagg

I wanted to make sure this is on the right track. Here's a screenshot of the special collection block and the inspector tools defined so far-

The idea is the new block would handle searching for record IDs (leveraging the lit api controller Sabrina's working on to get the data from alma) and parsing the results into the inspector tools and the data section in the middle. Should the middle section be mostly readonly, and just allow editing data in the inspector tools of the special collection block?

Once we settle on the structure, I was thinking of just creating a pattern with the layout if it'll allow the block to be locked, similar to how the locations post type uses patterns.

[spelkey-ucd]

@UcDust

A single block is fine, I think. You could also do multiple blocks. I see pros/cons to both.

I wouldn't use inspector tools. Use the middle section for your inputs (see rich text component). Have it match Kimmy's design as closely as possible.

And make sure you are saving your data to the page metadata section as opposed to block attributes.

[spelkey-ucd]

Also, move the Alma record ID and search button out of the block sidebar and into the collection sidebar.

[qjhart]

@UcDust, we are having a meeting here, where Kimmy is discouraging special collections from updating the slug to the call number, and using instead the more traditional title. This is just an FYI, to not worry about that update, until we hear more.

[UcDust]

Hi @wrenaria,

We met briefly with Quinn yesterday, and we're hoping to get your thoughts on the editor workflow. Here's a current screenshot-

You can see the Search Record ID button on the bottom right which can be used to fetch the data from alma. In the individual blocks we're thinking of adding undo/redo buttons. What we're imagining is a user could fetch the data, and then add more detail into the various blocks, perhaps adjusting descriptions or changing extent etc., but if they fetch the record again it would wipe out their changes.

We'd like to find a way to indicate that the text has been customized, perhaps some icon or highlighted text or something, and if they fetch and wipe out their changes, we could allow them to undo that change for individual blocks. And if they undo and decide they liked the fetched data after all, they could redo and bring the change back.

[spelkey-ucd]

@UcDust in your screenshot, the sidebar is showing and customizable. Nix that. It should be controlled by a widget area, which will allow us to show the same sidebar content across all manuscripts. It should already be all wired up.

[wrenaria]

@UcDust Tell me if these things are possible:

Sidebar Content

As Steve mentioned, this is handled via the widget area. You do not need to build anything in this area, that is for me to do (the content already exists as reusable content blocks in Stage and just need placed). My mockup is out of date for sidebar anyway.

Denoting Customization

For denoting that a section has been edited, display a red (strawberry) asterisk in same text/weight as heading next to the heading of the section has been altered:

Undo/Redo

Instead of individual undo/redo per local field menu, I would prefer you use the existing undo/redo buttons that persist in the page's top bar menu to undo/redo each change that is made to the page (this is how it works on other pages, it is what editors will expect).

Updating Displayed Data

If they fetch new information, update any section that has not been customized, but do not overwrite any customizations that have been made (but do store the data). Have a "restore" button that will restore the data as imported from the source. This is the way that other blocks manage their data / behave if you change the source.

For example, here are "restore" options on Marketing Highlights:

The options in the dropdown example above exist as part of the source page data, and if the source changes, so do the fields/image on the marketing highlight except for the items I've manually overridden. This is true even if I completely change the page I am linking to. Generally, you do not want to overwrite people's custom work automatically. It's better to to let them make the choice field-by-field themselves with the ability to Undo their decision using the top menu undo/redo buttons.

If you want to manage "restore" field by field on the page, that's fine, just have the single restore button active or not active on the local menu bar (no dropdown needed) with mouseover text "Restore Biography to default" or something similar.

In general, I want to maintain our existing UX patterns for editors where possible.

[UcDust]

@wrenaria, you got it, this should all be possible. Thanks!

[UcDust]

@spelkey-ucd

Is there a way to create a template/pattern for the all the collection blocks that we could change the layout of later and automatically update all the existing posts' layouts? For example, if later we decided to swap the places of Extent and Subject, we're hoping all collection posts could reflect the change.

It seems like the pages general structure is getting saved with the post, and even if we use a pattern to template the initial post structure, changing the pattern would only affect new posts that are created.

[spelkey-ucd]

@UcDust Correct, post templates are not dynamic. Wish they were! It would be very doable for locked templates. However, as it stands now, If there is a change to the template, there will have to be a corresponding data update (either through API or SQL). We will have to decide what the best strategies for this are.

[UcDust]

@wrenaria @spelkey-ucd A couple of the design pages show an image in the collection. Should we just have another column with an image block type, and if they save an image to the post then display it on the public side?