hexabinaer → created an issue.
The upcoming release contains a basic rework of the OC Map module. I've tested positive adding that filter. We have not added that filter in the default view yet. But assuming that given setups might have made their own customizations we will not update the OC Map views anyway. Feel free to add the event title filter.
After gathering feedback from site-owners we'll add that filter in the default view later.
As much as I support the responsible safeguarding ... reading through this thread I could not help myself but asking "What if someone had just been really successful in motivating new contributors?"
if they missed any community guidelines, I apologize for the same
Side task: Finding ways to give the Contribution Guidelines → more visibility where they might be needed?
You are kidding, right?
That would mean you are planning to let the module die for currently 763 sites.
Wop, wop, that was superfast, thanks! And good catch, the "//tile" part, I missed that one.
hexabinaer → created an issue.
Getting back to the table caption topic (context above still useful): Let's try and make screens readers only read out as much as necessary. The difference is: table headers (th, all dimensions) are being read out before the data cell in question. That makes sense for large data tables. Table captions are only read once, just like their headline character suggests.
Recommended WAI tutorial (very quick read)
Actually the horizontal table thead (currently containing "Day" and "time slot") is not even necessary here because it does not deliver essential information. Whereas the header cells in the first column do (that's why we patched that).
Ideally, an office hours table would be read like this:
"Regular office hours. Monday to Friday - 8 a.m. to 5 p.m. Saturday - 9 a.m. to 3 p.m. Sunday - closed all day."
And a season: "Winter season. Monday to Friday>/strong> - 9 a.m. to 4 p.m. ..."
That's why I would opt for <caption> as the tag for the season name and for consistency, for an additional "Regular hours" label as well.
Ha, now the penny has dropped :-)
I understand it's possible to simply display 2 seasons with opening hours. I forgot to mention that we do want to used the "Currently open/closed" status. And that's what does not work with this workaround.
Our platform deals with user-generated content. A typical user enters opening hours + exception days for a museum (default w/o seasons). Others enter information for an open air cinema, only open in the summer months. And some users maintain information about a point of interest that has regular (differing) summer + winter opening hours.
"Now open" will be the base filter for a map view.
I was just curious if I've missed some hack before writing a handout add-on. To keep the service up now we need make users understand that they need to update once a year.
I like that idea.
While at it, I would strongly wish for adding context to translations of "From" and "To" labels (separate issue?)
@johnv sorry for my responding so late. I was just about to say, yes, let's clarify the help text.
@robertom thanks for your idea. Appealing idea at first, I gave it a quick try but on second glance: for just 1 "infinite" season of course we can already enter the default office hours. Any "New season" entered afterwards requires start and end dates.
So as long as we cannot define yearless periods, I'd still suggest to change the text:
"Allows to register weekly opening hours for seasons, like 'Summer 2025'. This requires the Extended Weekday Widget."
joachim namyslo → credited hexabinaer → .
joachim namyslo → credited hexabinaer → .
joachim namyslo → credited hexabinaer → .
joachim namyslo → credited hexabinaer → .
joachim namyslo → credited hexabinaer → .
hexabinaer → created an issue.
Looking into it soon.
Just to let you know, I noticed one more: The season titles should rather be rendered in <caption> markup. Replacing the weekday table header cell with it might be confusing (arguably). It would be helpful for theming, too because season names might consume more space that the weekdays (especially when using 2ch or 3ch abbreviations).
I'll get back to that.
For context, using links (especially empty links) are setting up barriers. Since all action links are in fact triggers for functions, we provided a patch (see related issue) replacing them with submit buttons and providing audible feedback.
The approach to bundle the action links in a dropbutton was so appealing that we transformed that into a button-based dropbutton (see Paragraphs for reference).
Well aware now having two different further development approaches in two different issues. Hope we can merge that somehow.
I think setting a pager ID in the "My content" view should fix it.
Pager ID
Unless you're experiencing problems with pagers related to this view, you should leave this at 0. If using multiple pagers on one page you may need to set this number to a higher value so as not to conflict within the ?page= array. Large values will add a lot of commas to your URLs, so avoid if possible.
The other infinite-scroll paged views blocks on the dashboard seem to behave as expected after that change.
Why not simply disable the behavior "Extra style" in /admin/structure/paragraphs_type/teaser_wrapper?
Less testing on unintended side-effects required ;-)
You are right, this "My content" pager behaves not as expected. We need further testing. I know of no special OC tweak, just simple core config options.
My current user has more than 50 nodes. "My content" initially shows 1 Page 2 Page 3 Next page ›› Last page Last »
Change exposed pager option to 24: 1 Page 2 Page 3 Page 4 Page 5 Page 6 Next page ›› Last page Last »
Click on "Last": « First Previous page ‹‹ Page 1 Page 2 Current page 3 Page 4 Page 5 Page 6 … Next page ›› Last page Last »
I cannot reproduce a pager not showing up initially but I remember we had that phenomenon in an early version.
That's the "Related dates" view. I know the "OC Map" view has its performance issues but that's where our focus currently is. I'd tend to recommend your patch to those interested in this filter option. The OC instances where I have deeper insight all made customizations in one way or the other, especially in exposed filters.
@johnv re.
I guess you tested with the dropbutton issue implemented?
Not exactly but we took the understandable user story into account. Buttons would of course take up even more space than the links. tobiasb took another turn on the code, added comments (he says sorry for adding in late) and did some refactoring.
A follow-up idea would be to give site-builders the option to decide whether they want to wrap the options in a dropbutton or not.
Further answers to your questions (or new ones): let's use code comment threads to make sure we're still referencing to the same lines of code.
in OfficeHoursBaseSlot , you replace the links with 'button'. Not sure from the comments above, is this preferable to the dropbutton? is this preferable to the dropbutton? Is thisin line with the drupal
@johnv this is one of the major improvements for screen reader users: buttons trigger actions/behaviour whereas links should take you to a new page. It's about semantics, not about what the element looks like. That said, a dropbutton ist just a wrapper (that must be accessible, too, of course) to save space in complex UIs. We know the concept from Views (legitimately wrapping operations links as well as from the optional Paragraphs dropbutton widget (wrapping buttons).
It is an ongoing process to replace inappropriate elements, in core as well as in contrib.
Yes, of course, glad you're asking :-)
- kulturis is a regional arts + culture platform with a vivid magazine. Launched in 2022.
- THEATRIS is a branch-related platform with a focus on an archive for the independent performing arts. Launched in 2022.
- CMS Garden is the proof-of-work that it's suitable for FOSS-related communities, too. Relaunched on OpenCulturas in 2024 after 10 years on Drupal 7.
- OpenCulturas the complimentary website uses the distribution, too, of course. Launched in 2023.
- GzEvD - the Company for the Development of Things is even using it for a company website.
There are 2 more implementations with upcoming launches very soon, both focused on presenting rather rural regions rich in culture. We are trying to keep track on setups on the Showcases page on OpenCulturas.org
Oh, I wasn't aware of that. Thanks for the research!
If quickly checked in 8.x-1.19:
- Office hours (week): Action links work as expected
- Office hours (list): Action links + "Add another" work as expected
Why the links should rather be buttons anyways: see Fix accessibility issues in form 📌 Fix accessibility issues in form Active
hexabinaer → created an issue.
@mrshowerman On trying to construct a link with tokens there's a glitch:
- Click in either of the 2 fields
- Open token browser
- Select a token, e. g. [geofield:latlon]
Always results in a modal message "First click a text field to insert your tokens into.".
I accidentally posted my question in another issue of yours → , so sorry.
Looking into it, the approach makes sense for the related_date view.
However, I doubt it will work for oc_map_dates because as far as I remember this filter would not be reflected in the module's code. Have you really successfully tested that filter in an "OC Map"?
Oops, so sorry. #3 was related to a different issue :-}
Good point @moritz.steinhauer. This might be very dependent from how calendar content is created and how site owners set the rules.
It makes sense when events + corresponding dates are imported and published by default. However, we can have different scenarios.
Maybe a more generic solution would rather be found with an optional ECA function and let site-owners decide to unpublish or even delete dates related to the event in question?
Upon second thought, I might make sense to change the publishing workflow for dates then (default published). As a second step.
Looking into it, the approach makes sense for the related_date view.
However, I doubt it will work for oc_map_dates because as far as I remember this filter would not be reflected in the module's code. Have you really successfully tested that filter in an "OC Map"?
Awesome, I'll look into it.
On first reading of your description I wondered if this could work as a generic module (without OC dependency).
hexabinaer → created an issue.
On evaluating, this issue title alarmed me. Tried nevertheless and can confirm: works as designed. Handler does the magic.
Side note: Add "case insensitive" to the description. I had collected e. g. "unsubscribe" and "UNSUBSCRIBE" beforehand, unnecessarily ;-)
I would assume the easier way is to enable interface translation to English /admin/config/regional/language/edit/en and use User Interface Translation for custom labels.
At least as long as Drupal core does not support a differentiation between form labels and output labels.
Probably not an issue any more.
We're using this module in the OpenCulturas distribution. Oddly enough some site owners report exactly that issue while others get no message at all any more (neither on unsaved-leave nor on save button). I can reproduce both phenomenons with my setup (Firefox, no adblockers + co). Testing with several roles.
We're still analyzing reproduceability, just to let folks know.
For completeness:
@mandclu reading on in the mentioned "phrasing content" list you'll find elements with specific conditions.
<a>, if thehrefattribute is present
This is still the case in the current 8.x version. Comparing to a second project where SbT delivers quite satisfying results while in my current project we have very nested hierarchical vocabularies, I reckon this might be related to a miscalculation of (counted in) term children.
Right so :-)
hexabinaer → created an issue.
Yes sorry, I might have been mislead. The conversion from float to integer is probably totally unrelated.
However, I am still puzzled why the relevancy is always "1", no matter what operator I set, e. g. "Contains any of these words" (parse mode for fulltext search is "Multiple words")
This is an unfortunate known issue. To be honest, we didn't take it seriously enough because it appeared during test nodes cleanup. To avoid unintended damage, we introduced the "unpublish" workflow state and restricted the node delete permissions to higher privileged roles.
But now that the scenario has been reported for the 3rd time already (2 off-platform) we should find a robust solution.
I am still having a hard time understanding the user story that makes people delete a (reusable) event description. Understanding the situation would help deciding upon one of the possible solutions.
By the way, the solution must handle any entities that are referenced by a mandatory field as well. Plus cleanup of non-mandatory fields like article "mentions" references.
The decision is to be made between these 2 principles
- Disallow deletion with reference to dependencies (feedback information page lists referencing nodes linked)
- Bulk deletion based on dependency detection (confirmation page lists current and referencing nodes, confirmation option complete - or cancel)
I ran into the same, trying to combine content type and media type in a single facet. Setting identical URL aliases and ignoring the warning is no workaround btw.
Whatever setting you try, the facet link will be invalid and issue an empty search result.
+1 from me!
This behaviour was indeed unintended. (As you see in the address paragraph default display, avoiding the mouse wheel trap was always planned.)
Joachim Namyslo → credited hexabinaer → .
Thanks for noting this! If nothing less it helped me understanding what my current problem is.
Beim Lesen der Kommentare bekam ich kurz Puls, weil das ja keine Frage von Entweder-Oder ist :-D Aber darauf lief es ja gar nicht hinaus.
Ich denke, wir sollten die Validierung in die gitlab CI Templates mit aufnehmen, damit alle Module bei jeder Änderung immer automatisch geprüft werden und die Entwickler eine Fehlermeldung erhalten, wenn ein string falsch ist.
Jawoll, das brauchen wir auf jeden Fall. Unterstützung bei der Fehlervermeidung wo immer es geht. Deshalb bin ich ja auch für das Rausschreiben von fehlerhaftem HTML beim Übersetzen. Nicht als einzige Maßnahme, aber eine, die die Nerven derjenigen schont, die Übersetzungen importieren.
Bei unseren eigenen Patzern sind wir dazu übergegangen, als erstes die Übersetzungen zu fixen, einfach weil's schnell geht. Wir notieren die Übersetzung zusammen mit den Source-Korrekturen, so dass wir sie schnell zur Hand haben, wenn das nächste Release rauskommt.
hexabinaer → created an issue.
Sure, let's do that!
Awesome, thanks! Will look into it shortly.
hexabinaer → created an issue.
hexabinaer → created an issue.
Ah yes, I should have had a look at the Log before writing:
Deprecated function: Implicit conversion from float 0.75 to int loses precision in Drupal\Core\Template\TwigExtension->withoutFilter()
hexabinaer → created an issue.
A client of ours reported the same issue und now they want a reroll to CKEditor 4 :-D
Admittedly the "missing link" in this evolution is rather that the regular CKEditor link widget is not prepared for anchor links (maybe allowing to enter anchor names but then not allowing to edit the link).
In case patching that widget would be too effortful: It should be reasonable to introduce a complimentare extra button/widget just for adding anchor links. The icon could combine chain link + flag.
tobiasb → credited hexabinaer → .
@AstonVictor hint for next time ;-) https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →
Adding related issues, I think this issue will be answered be one of these.
What is it meant for, anyways? It even appears in the table head when there are no orderable items.
It would help mitigation when the th cell had a css class.
Fix in the making. A context filter will exclude the current delta in the URL (?date_delta=n) and handle a NULL fallback.
Trade-off: When the date page has no delta parameter (e. g. after adding a new node) the list will show all date instances, including the one shown on top of the page.
I think this will cause the least confusion. Again, thanks for pointing out.
The challenge is this: simply removing the offset in the "alternative dates" display would result in an always rendered block that repeats the very same date instance.
We need to find a way to exclude the current date's delta from the rendered list.
Your question is indeed related to Search API, not this module. There is quite a lot of documentation available for all flavors of search. Move onwards from https://www.drupal.org/node/1250878 →
In short: First configure an index (which you might have already done). Then add a view (/admin/structure/views/add) based on your Meilisearch index. Expose a fulltext search field. That's basically it.
I am reluctant. Admittedly this is the more modern approach and surely makes it nicer for sighted users. Have you checked back with different input devices in all instances?
Sounds good, makes absolute sense.
Oh my, you are right. QA failed. Thanks for pointing out!
hexabinaer → created an issue.
Joachim Namyslo → credited hexabinaer → .
For the record:
For the initial version we had discussed both variations: results tagged with current term including/excluding child terms. There are arguments for both because it depends on how hierarchical tags are used. For example, when music events are always tagged with music and the suitable child term, the difference in drilling down would be "discovery" vs. "filtering".
I am changing the category to feature request just for the sake of respecting both scenarios as valid. Whoever finds this may get an idea of where to make changes for the "excluding child terms" scenario.
Joachim Namyslo → credited hexabinaer → .
Makes sense, absolutely! I reviewed the diff and opt for a merge.