Omeka s 4.x.x new block

[mquantin]

Hello,

I migrated to omeka-s v4.0.4 recently.
I had a very long, ugly and convenient custom version of view/omeka/site/item/show.phtml in my theme.
In that file I wrote php functions and php rendering lines to show up some (filtered) data from some (filtered) linked items. (see issue1966).
I also created some viewFile for displaying, in an item page, the content of another item.
Now I should port this to block layout

I read the doc for dev and I’m lost.
I think I need to create a new block (or more).

This doc page “module/Page blocks” is a basic requirement only.
btw why is this page sorted in the “module” section, and not “theme” section?
→ should I

1. first create a module that does the job (gathering and filtering),
2. then create a theme which call this “job” to be displayed?

Indeed the new block definition (extending the AbstractBlockLayout) seems to be located in src/Site/BlockLayout directory. This directory not rewritable by the theme, is it?

In the doc, elsewhere, I also found the section Updating An Existing Custom Show Page to Use Resource Page Blocks. But no new block is displayed, only existing standard blocks are re-used.

What are the files I have to create, and what should they contain?
I’m sorry I’m really into php and MVC architecture (but react ).

I can’t find any example of a definition of a new block used to show something new in e.g. item/show.phtml
An example is really what I need.

Is it a very special case?
Is the doc clear about this and I didn’t succeed in understanding it?

thank you for your help.

[jflatnes]

So, there’s a couple things going on here.

First, the first manual page you pulled up, the “page blocks” one: that’s about the blocks used in Site Pages, the pages users can fully customize and input data. They’re really designed only for modules (or the core) to add them, so that’s why that is in the module documentation. They’re not used for pages like item/show.phtml like you’re discussing.

The newer feature that does relate to item/show.phtml is “resource page blocks.” That one deals with themes having regions where users can move around the parts of the show pages for items (and media and sets), and turn on and off individual parts of the display. The problem for your use case is, as we initially conceived them, these are also really focused on the blocks themselves being provided by the core or a module. The idea was to take the things we have in the standard themes, and things added by modules, and give users a way to configure those things without needing to edit a theme.

There isn’t currently a system for the theme to add its own “resource page blocks” like you’re talking about here. To do it today, you’d have to have a module that adds the resource page blocks. Of course, your use case is a reasonable one, though. I’ll think over a little if we can make themes be able to do something themselves with this system. We’re looking at some other features that aren’t quite the same but are somewhat related, dealing with the user-editable pages and giving themes more ability to customize those.

As for what you could do today: I mentioned above that you can add resource page blocks with a module and that’s one option, but it means splitting up your theme’s functionality in a way you might not want to do. You can of course just leave it as-is, so your theme just doesn’t support the resource page blocks at all and just uses your custom item/show.phtml (letting themes continue to do this was a goal of how we designed the feature).

There’s also two things you could do as a kind of middle ground. For one, you could provide a region (or multiple regions) in your show page that allows for the configurable blocks, but also keep your custom ones. You get to choose which blocks are selected by default, so you could leave out ones that are duplicated by things your theme has customized. This would still give users the control the feature provides over things added by modules and other optional items.

The other thing that could work for you is: the views for each of those core-provided resource page blocks are themselves theme partials that your theme can override. So if you have something replacing the linked resources view for example, you can, instead of overriding the whole show page or providing your own block, override the view/common/resource-page-block-layout/linked-resources.phtml view in your theme (and so on for the other blocks).

[mquantin]

Oh thanks a lot,
After reading and reading the doc I ended understanding a little bit the new architecture.
With you post, this new architecture is now totally clear.
The backward compatiblity of the new pageBlock feature (with old view pages) is a great news for me.
The options you describe are helpfull and I’ll probably mix the two last ones :

• customize existing blocks, like linked-ressources one
• write directly php functions in the show page (the old way), skiping the creation of new block.

→ So I won’t have any new block, I’ll keep part of my old code in the showpage side by side with the block calls. Some of these block are “standards” ones, some others are customized (by the theme).

best regards,

[mquantin]

@jflatnes, is there a way to call services in a theme helper ?
Are factories only for modules?

I don’t understand these restrictions… why can’t the helpers access the services?
My fallback solution is to have no helper (or very few), and all the code in a single show.phtml file.
… mmmmh i’m really not into PHP ! please help

[jflatnes]

The system for registering helpers for themes is intentionally very simple, so there’s no provision for having a factory. This isn’t an inherent restriction, it’s just down to how we’ve implemented the themes.

What service or services do you need access to? Some that are commonly used in themes we have existing helpers for, so they’re no problem. If you can write what you need directly in the show.phtml, in general I’d think you could write it in a helper without needing a factory.

[mquantin]

okay thank you for that help.

I need to call the api to filter the result $resource->subjectValues(). I need to get more info about some resource_classes. I also call API to have linked items based on a property list.
$api->searchOne('properties', ['term'=>$skipedPropTerm])->getContent()->id();

I tried to call $api = $services->get('Omeka\ApiManager'); but It’s not accessible…

If it’s not possible, I can do it outside the helper and without the api. But it was clean and confortable!