Add Notifications CMS functionality

[jschultze]

This pull request adds the Notifications mini-CMS functionality to VuFind. It is developed by effective WEBWORK GmbH in cooperation with hebis. Notifications allow the creation of simple, CMS-like "pages" that can be accessed via a new menu in the header area. Also short information "broadcasts" can be displayed in the header area and on the search home.

Markdown is used to compose the content, and different translations for all currently enabled languages are possible. Pages and broadcasts are edited from the Admin-area of DSpace.

TODO

• Port database code to PostgreSQL

[demiankatz]

Thanks for sharing this, @jschultze! I'm currently focusing most of my time on finishing up the 9.1 release, but I will give this a review once development begins on 10.0.

[jschultze]

Thanks @demiankatz !

There seems to be a request for additional functions that came up after WOLFcon - hebis jut informed me about that. I will look into it in the next week, and maybe I can include that in the pull request before you start with the review.

[demiankatz]

Great, thanks, @jschultze!

[demiankatz]

@jschultze, just a couple of very high-level observations from a quick look at the code. Since you said more changes might be coming soon, I haven't given this a deeper review yet, but I thought it might be helpful to at least get a conversation started here. :-)

[demiankatz]

Based on discussion with @ThoWagen on today's Community Call, I have given this PR an "on hold" label since I know there is pending work that we expect to have added at some point in the future, and it's probably best to delay review until that is completed. Please let me know when you're ready and I'll be happy to remove the label and resume reviewing.

[jschultze]

@demiankatz The functionality is ready and I will start looking into the first observations that you mentioned above.

[demiankatz]

Thanks, @jschultze, I'm removing the "on hold" label and will give this another review soon. I notice that there are some minor conflicts that need to be resolved here. Would you like help resolving these? If so, just let me know and I'll take care of them at the same time I do my review.

[demiankatz]

@jschultze, I had a few minutes free today, so I went ahead and resolved the merge conflicts as well as applying some of the standard style fix tools (php-cs-fixer and phpcbf). I didn't have time for a full review, but I skimmed through and raised a few more points for discussion (see below).

[demiankatz]

How critical is jQuery UI to this PR? We are currently in the early stages of removing all jQuery dependencies from the codebase, so I'm reluctant to add a major new dependency if it can be avoided...

[jschultze]

I think it is only used to enable a tab for each configured language in the edit forms for pages and broadcasts. The reordering of entries in the list view to change the displayed order is done with the DataTables library.

Is it just a problem using jQuery UI particularly, so that I can try and find a smaller, independent library for the tabs? Or should additional JavaScript libraries be avoided?

[demiankatz]

We already have tabbed interfaces in a couple of places (most notably on the record page) without introducing additional dependencies. I confess that I can't remember exactly how those are implemented, but it might be worth looking for precedent before adding something new. Or, if adding something new is valuable, maybe it should be applied to all tabbed interfaces for consistency.

In any case, I'm certainly not completely opposed to adding a dependency if it's a significant time saver or improves the user experience. I just try to avoid them unless absolutely necessary because they often lead to future technical debt.

[jschultze]

I'm currently trying to refactor the notifications language-tabs to the way tabs are implemented on the record page.

[jschultze]

I did not get the tabs from the detail view to work in the notifications context, so I build a small JS/CSS tab navigation myself. jQuery UI is removed.

The less and sass files are included. Should all the generated files be committed too?

/themes/bootprint3/css/compiled.css
/themes/bootstrap3/css/compiled.css
/themes/bootstrap3/css/vendor/simple-keyboard/index.css
/themes/bootstrap3/js/vendor/chart.js
/themes/bootstrap3/js/vendor/simple-keyboard/index.js
/themes/bootstrap3/js/vendor/simple-keyboard-layouts/index.js
/themes/local_theme_example/css/compiled.css
/themes/sandal/css/compiled.css

[EreMaijala]

@demiankatz composer update-npm-dependencies (or npm run updateDeps for a single theme) doesn't allow you to do it for a single package and can cause side-effects unless you're careful.

[demiankatz]

Good point, @EreMaijala. I guess we need to decide on a strategy here. I think there are two general approaches:

1.) We pin all dependencies, and add composer/npm tasks to help identify pinned dependencies that are eligible for upgrades.

2.) We leave dependencies unpinned, and I open a separate PR to upgrade and test everything, and then we merge that separately to remove extraneous changes from this PR.

Any preference?

[demiankatz]

For now, I've opened #3522 to bring things up to date independently of this PR... but I'm still open to discussing long term strategy independent of that. :-)

[EreMaijala]

@demiankatz I don't have a strong preference, but pinning would be consistent with composer dependencies and would avoid the situation here where just trying to add or update one dependency will easily cause side-effects.

[demiankatz]

It occurs to me that the best solution might be to start committing the lock file. Can you think of any reason not to?

[jschultze]

@demiankatz @sturkel89 I committed fixes for the comments regarding translation keys and the configuration file.

Regarding the sticky date: I tried to replicate the behaviour on my local machine wit a Firefox set to "English (US)" as language. This results in a form that seems to display the dates right:

Creating and editing the dates works without any problems. What I can only see if I delete all date info by hand are empty fields with just the placeholder "mm/dd/yyyy" displayed. When I create a new broadcast, the current date is set as the default value. So I can't really recreate this bug on my side.

What I found, and maybe is a solution: in the Form-class for Broadcasts a standard format was configured for start- and end-date.

'options' => [
                'label' => $this->translate('broadcasts_startdate'),
                'format' => 'Y-m-d',
            ],

I removed that option. The behaviour does not change, but maybe that was the detail that fixes the forms in your environment also.

[sturkel89]

@jschultze I'm still finding that when I EDIT an existing broadcast, the dates immediately go blank. That is the only problem I'm concerned with.

Here's the broadcast in dashboard view:

Then I click the Edit icon, and here's what I see:

The text, the checkbox for "visible on every page", and the color choice of blue are all still there and ready to be edited. But the dates have reverted to the placeholder mm/dd/yyyy. I would expect the dates I selected previously to still be present in this editing view. Do you have a different experience of this? I see the same thing in Firefox and Chrome on Windows.

[demiankatz]

I wonder if this problem has something to do with locale settings...

[sturkel89]

I tested the branch again with the locale settings changed to de_DE. The date settings for notification broadcasts still reset to MM/DD/YYYY when I went to edit my test broadcast. So, I don't think that locale settings are the explanation for this behavior.

@jschultze , when you create and then edit a test broadcast, do you find that the dates that were set initially are present when you switch to the editing view?

[demiankatz]

Since time is running short for 10.1, I have moved this to the 11.0 milestone.

[jschultze]

@sturkel89 Yes, editing an existing broadcast keeps the dates:

Chrome, set to de_DE:

Firefox, set to en_US:

[maccabeelevine]

This is a great feature addition and I hope to see it completed so I can use it!

Evaluating only the issue that @sturkel89 reported, I am seeing the same problem. When editing an existing broadcast, I lose the dates. I did some research below into why it's happening but I don't know anything about Laminas Form so can't say how to solve it for real.

[maccabeelevine]

After loading $broadcast, I see that the startdate and enddate elements are datetimes i.e. 2024-11-05 00:00:00, which makes sense since the schema defines those fields as datetimes. There is some logic within Laminas form which is corrupting that (I think) so that in FormElement->render(), the $renderedType ends up as "<input type="date" name="startdate" class="form-control" value="2024-11-05&#x20;00&#x3A;00&#x3A;00">", which I think is what messes up the display.

I can fix this right after this line by truncating off the time parts:

            foreach(['startdate', 'enddate'] as $dateField) {
                $broadcast[$dateField] = explode(' ', $broadcast[$dateField])[0];
            }

But there must be a better way to resolve this. I'm not sure if the schema has to use datetime in the first place if the UI accepts only date values, unless this is trying to be flexible in case we do store times in the future.

[jschultze]

@maccabeelevine Thanks for the test! I was about to try this change, but checked the generated HTML on my local system first for the corrupted HTML. And here seems to be the difference to your test and those of @sturkel89 . I get this HTML:

<input type="date" name="startdate" class="form-control" value="2024-07-11">

So I checked my local database and the schema is date not datetime. I'm sorry that I missed this before and I can not recall why this setting does not match the schema given in mysql.sql!

@demiankatz Will a date be enough, or would you think it should be possible to set exact times? We tested this functionality with two communities (hebis and Qcovery) and I don't think that setting the exact time has been missed.

[demiankatz]

I can imagine there might be arguments for either granularity, but if your existing user base has found date granularity acceptable, it seems reasonable to at least start there. If we need date/time, nothing is stopping us from adding it as a future option. (Of course, if it's trivially easy, maybe it's worth adding a config setting now... but I suspect it is not trivially easy, and I don't want to make the workload here even larger!).

[jschultze]

I started working on additional time settings, but realized that it will probably be better to get the first version on this feature finalized - assuming that the whole community will have ideas for further development in the future and we will be working on this anyhow.

I changed the settings in mysql.sql from datetime to time and added the three small changes that @maccabeelevine proposed (although setting 0 as default for priority).

[maccabeelevine]

I get an exception on this line, I believe it should be

if (($broadcastData['id_' . $language] ?? null) == null) {

or maybe just

if (!($broadcastData['id_' . $language] ?? null)) {

[maccabeelevine]

I get an exception here, no priority field. I was able to get past it with

            $broadcast->priority = $data['priority'] ?? -1;

but there may be a better default.

[maccabeelevine]

I got errors on these fields as well and had to protect them with ?? null.

[demiankatz]

Thanks for the progress, @jschultze (and thanks for the assist in getting us unstuck, @maccabeelevine). How would you like to proceed from here? Would more testing be helpful? Do you want to start working on bringing the code more up to date? Do you need assistance in any particular areas?

[jschultze]

@demiankatz If the code is now working on your side, I would start with the update of the code to the current state of VuFind, yes.

[demiankatz]

Thanks, @jschultze! @sturkel89, can you give this another look when time permits?

[sturkel89]

It's fixed!! I've set up a couple of broadcast messages, and when I click the edit icon I see that all of the elements of the broadcast are available to be edited, including the dates!

I tested changing the dates, and the new dates saved correctly. As far as I can tell, all is working properly now. Thanks, @maccabeelevine and @jschultze!

[jschultze]

Thanks for the test, @sturkel89 I will start with to update the code to the current version of VuFind.

[jschultze]

@demiankatz I merged the current dev branch into this pull request and added support for the bootstrap5 theme.

[sturkel89]

I reviewed this PR with special consideration of the updates to the new themes.

FRONT PAGE ISSUES

Notification banners that are supposed to appear on the front page are NOT functional in the new themes, although they appear normal in the legacy themes.

bootstrap3:

sandal:

In the new themes, the banners DO NOT APPEAR on the front page, at all.

sandal5:

---

OTHER PAGES ISSUES

Notifications banners appear in both legacy and new themes in VuFind subpages (i.e., item pages, results list pages) but their formatting is different between legacy and new themes.

Notification banners stretch across the screen in the legacy themes:

bootstrap3:

sandal:

In both new themes, the banners appear in the top corner, pushing the Theme and Language dropdowns to the middle of the screen.

bootstrap5:

sandal5:

Also, the other issues I noted in my earlier reviews are still problems:

• I can't get any popover explanations for some of the icons on the management page (eyeball, globe)
• Clicking the X in the notification banner does not make it disappear.

---

NOTIFICATIONS PAGES

Notifications pages are functional, in that the text links to the notifications pages appear on the home page and the other pages in all themes.

The locations of the links are a little awkward in the new themes. In the legacy themes, the links are aligned with the word or icon for VuFind. In the new themes, they are in the middle of the page but above the VuFind.

bootstrap3:

Same browser, bootstrap5:

sandal:

Same browser, sandal5:

With narrower screens, the break points for hiding the notification page links inside the hamburger menu are different between legacy and new themes. There are many different breaking points and variations, so I didn't document them.