The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I've created a small module for a client that allows one to enter a single set of default office hours, along with option exceptions, and provides an hours listing block and an open/closed status block, and I submitted a project application for it. You can see that here: http://drupal.org/node/1535698
Before it's approved though, it was suggested that I contact you to discuss merging the features unique to my module into Office Hours instead.
It would be a bit of work, but might be worth the effort, especially if you feel that that the features would be welcome in your module.
The important features of Simple Hours are:
- Ease of setup and configuration.
- Immediately available listing and current status blocks. The current status block was important for this client. The idea is that the block will display "Open" or "Closed" text based on the current day/time.
- Entry of hours exceptions. These are both for easy, uniform display and for the calculation of the open/closed status.
I could imagine including a help module that would create a new content type with an hours field, some sample content, and better docs to help with the ease of setup and configuration.
I can also imagine a setting that allows users to create blocks for nodes with hours fields attached, and a new formatter for displaying the current open/closed status.
So, are these features that would be worth the combined effort to include in Office Hours, or should I keep them in a separate module and move forward with the project application?
Thanks for your time!
Comments
Comment #1
johnvI like your work, Jeff,
And it would be nice to incorporate the simple Office code.
It looks like your module Simple Hours (SH) is a D6-version, and given the Usage statistics for Office Hours (OH), it would make sense to do this in the D7 version. How about that?
Most of your features match the Open feature requests for Office hours, like:
#1168126: Default value for every day of the week
#696262: Show Status 'Open/Closed (now/today/soon)' in Views
#1168172: Widget redesign for 'days with same opening hours' : group together or provide a copy/paste functionality
After a quickscan of your code:
SH has only global values. This makes the install very simple, since you don't need any tables. This makes it suited for a personal website.
OH needs a carrier, like a node, which requires a bit more config. We could make SH a submodule of OH (or al reverse, make SH dependent of OH), so you can reuse all calculations.
(BTW, the calculating functions have not/hardly changed between D6 and D7, so you could make a plugin for D6, and develop further for D7)
- The 'Exceptions': would be a great enhancement
- The 'Hours' block: we need to find a way to -reuse the formatting options of the OH field. Perhaps we can provide this a default view/View Template? This requires a Views dependency..
- The 'Status' block is nice. As a follow-up, a function/field isOpen($node = NULL) would open the way for a Views field.
- The 'Default values': OH has no good default value - yo can only set the Sunday-value. Perhaps the SH settings might provide a good method of storage.
We might work on this on a feature-by-feature/per-issue basis.
Comment #2
jeffamHi John,
Sorry for my delayed response.
I like your ideas about working on the D7 branch a single feature at a time.
Since my client's needs were met with Simple Hours, I'd have less time work on this, so keeping tasks bite-sized would be nice.
Using default views for blocks is a great idea, too. We could simply provide them in the module, but Views wouldn't necessarily be a dependency. The view(s) would just be there if Views was enabled.
I just played around with the 7.x version on a test site, and I really like it. The display formatters are flexible (though hidden), and it's pretty easy to use views to add a block for a specific hours node, formatted as desired.
Seems to me that the most useful features to add would be:
- Exceptions, although they are only really needed when there is a way to show the current open/close status. Otherwise, they could be accomplished with another date field on the same content type.
- Current open/closed status. In my use case, this would require structured exceptions, so that the module wouldn't accidentally show an open status on a day that was closed for, say, a holiday.
- Default blocks
- Maybe an optional default content type, to get folks started a little quicker
- More documentation, to help people configure some of the more obscure settings or get started more quickly
Comment #3
johnvMoving to D7, since that's where it will happen.
Comment #4
johnvRegarding the remaining features in #2:
1. Exceptions, see #1743366: [Season Meta] Add "Seasonal Hours / Duration" feature
2. Current open/closed status. This feature now exists, but will break when Exceptions/seasons are implemented
3. Default blocks: I've added a script to the README.text file.
4. Maybe an optional default content type, to get folks started a little quicker: seems a bit of an overkill, since it is a 'normal' Field.
5. More documentation: I've amended the REAMDME.txt file.
So, as an overall status, I'd say this issue is fixed.
As a reference, your project application: #1535698: Simple Hours
Comment #5
johnv