Functional Request

@obewanz I don’t understand this request.

The aside element is used for the sidebar within the template as an aside section. I don’t see how adding this to the HTML output of the widget would help with anything (which could easily end up with one aside within another).

Do you have a URL example of a widget having aside in its output like you suggest?

Your widget is the only one loaded on my development site that isn’t being loaded in an aside wrapper element…

<div id="secondary" class="widget-area sidebar" role="complementary">
	<h2 class="widget-title">Business Hours</h2><table class="opening-hours opening-hours-widget">
	<tr class="day monday past weekday">
		<th class="day-name">Monday</th>
		<td class="hours">9am – 5pm</td>
	</tr>
	<tr class="day tuesday past weekday">
		<th class="day-name">Tuesday</th>
		<td class="hours">9am – 5pm</td>
	</tr>
	<tr class="day wednesday past weekday">
		<th class="day-name">Wednesday</th>
		<td class="hours">9am – 5pm</td>
	</tr>
	<tr class="day thursday past weekday">
		<th class="day-name">Thursday</th>
		<td class="hours">9am – 5pm</td>
	</tr>
	<tr class="day friday past weekday">
		<th class="day-name">Friday</th>
		<td class="hours">9am – 5pm</td>
	</tr>
	<tr class="day saturday past weekend closed">
		<th class="day-name">Saturday</th>
		<td class="hours">Closed</td>
	</tr>
	<tr class="day sunday today weekend closed">
		<th class="day-name">Sunday</th>
		<td class="hours">Closed</td>
	</tr>
</table>

		<aside id="recent-posts-2" class="widget widget_recent_entries">
		<h2 class="widget-title">Recent News</h2>
		<ul>
											<li>
					<a href="/common-electrical-conductor-types/">Common Electrical Conductor Types</a>
									</li>
											<li>
					<a href="/backdrafting/">Backdrafting</a>
									</li>
											<li>
					<a href="/aluminum-wiring/">Aluminum Wiring</a>
									</li>
											<li>
					<a href="/afci-testers/">AFCI Testers</a>
									</li>
											<li>
					<a href="/10-easy-ways-to-save-money-and-energy-in-your-home/">10 Easy Ways to Save Money & Energy in Your Home</a>
									</li>
					</ul>

		</aside><aside id="categories-2" class="widget widget_categories"><h2 class="widget-title">Article Categories</h2>
			<ul>
					<li class="cat-item cat-item-5"><a href="/c/home-and-commercial-building-systems/electrical/">Electrical</a>
</li>
	<li class="cat-item cat-item-3"><a href="/c/energy/">Energy</a>
</li>
	<li class="cat-item cat-item-7"><a href="/c/home-and-commercial-building-systems/heat-air-ventilation/">Heat / Air / Ventilation</a>
</li>
			</ul>

			</aside><aside id="archives-2" class="widget widget_archive"><h2 class="widget-title">Archives</h2>
			<ul>
					<li><a href='/2022/12/'>December 2022</a></li>
			</ul>

			</aside>
			<aside id="custom_html-2" class="widget_text widget widget_custom_html"><h2 class="widget-title">Trusted Area Professionals</h2><div class="textwidget custom-html-widget">
			<p>Insurance: Farm Bureau Agent</i></a></p></div>
			</aside>
</div>

So, just to recap the html output above – 4 out of 5 widgets are wrapped in an aside element.

The bonus is that you can be specific when targeting a widget for CSS customization, which may also allow you to change the way the sidebar components are displayed in a variety of ways within a given theme.

I can choose to add a color to the background of the custom html widget simply by targeting the id “custom_html-2” or I can target the class “widget_custom_html” for more specific customization.

As an example, I can use the following CSS to give the hours table rounded corners with a shadow:

table.opening-hours-widget {
 border-collapse: separate;
 border-spacing: 0;
 border: 1px solid #ccc;
 -webkit-border-radius:7px;
 -moz-border-radius:7px;
 border-radius:7px;
 -webkit-box-shadow:3px 3px 6px -1px rgba(0,0,0,0.2);
 -moz-box-shadow:3px 3px 6px -1px rgba(0,0,0,0.2);
 box-shadow:3px 3px 6px -1px rgba(0,0,0,0.2);
}
.opening-hours .day-name {
 padding-inline-start:0.8em!important;
}

…but I cannot target the widget with enough specificity to use a pseudo element to add something like a footer that would tell folks to check my schedule for availability… well, actually I can target the table, but because the output is in columns, I cannot make the footer span the width of the table. If I could target the widget using an aside id and/or class (as other widgets in the first code section) I could do this without modifying the widget code. To further illustrate – the following code shows how I customize the custom html widget to set it apart from the other widgets using this technique:

/* CUSTOM WIDGET ASIDE CHANGES */
div.custom-html-widget.widget-title {
 text-align: center;
 text-transform:uppercase;
}
div.custom-html-widget a.tap-link {
 color: #bb133e;
 text-decoration: none;
}
div.custom-html-widget a.tap-link:hover {
 color: #e10038;
 text-decoration: none;
}
#custom_html-2 {
 background: #efefef;
 border-radius: 8px;
 padding: 5px;
}

• This reply was modified 1 year, 10 months ago by obewanz.
• This reply was modified 1 year, 10 months ago by obewanz.

@obewanz I will look into the best-practice approach this week and add new functionality if required.

The reason why I question having aside (within the plugin’s output) is the theme usually places the entire sidebar as an aside itself. The first div with <div id="secondary"> is frequently an <aside id="secondary"> element – because that whole section is “aside”, not just individual widgets.

Writing plugins that work with all themes can be almost impossible. So, I will look into the prevalence of what you mentioned and add something in a future release if this isn’t as rare as I thought.

With the CSS, I get that you may use aside in the rules, but it isn’t hard to be more specific. Just prefix all your rules here with #secondary and that will override most theme/plugin’s CSS. The widget version of the opening hours has it’s own widget class added to differentiate it between it and the standard Shortcode.

Perhaps, if you want to incorporate the opening hours in the current design approach you have there, why not use the Shortcode in a HTML widget instead? This would result in more standard enclosing elements.

Hmmm… Interesting… Because I run 7 different wordpress sites using 4 different themes and every widget, but yours, is wrapped in a uniquely identifiable element. The point is, without the widget output being wrapped in a unique element of some kind, your suggestion to use #secondary won’t work to target just your widget as any rule without more specificity than #secondary will be targeting all widgets with the sidebar. Looking at the html output of the We’re Open widget, the most specificity that can be accomplished is to target the hours table itself with “table.opening-hours-widget“. (Not to say you can’t target elements within the table – see last code block earlier.) However, if you want to target the We’re Open widget’s TITLE for customization – you cannot – without affecting all of the other titles in the sidebar because the widget is missing a wrapper. But if I want to change the way the “Article Categories” title is displayed, maybe to give it more visual impact for instance, I can use something like “.widget_categories h2.widget-title {color: red;}” to specifically target just the H2 element of the widget title (Note, in every case of the widgets I have deployed on those 7 sites I would not need to use the h2 element since none of them have any sub-heading text.) I have done exactly that sort of thing with this rule used to shade the entire widget output and round the corners to set it apart from the rest of the sidebar elements.

#custom_html-2 {
 background: #efefef;
 border-radius: 8px;
 padding: 5px;
}

Since the We’re Open widget doesn’t have a wrapper equivalent to #custom_html-2 it is impossible to accomplish the same thing on the We’re Open widget. The best I can do is target the hours table, the title, or the entire sidebar.

How the other widgets accomplish this is not something I have not looked into – seems to me it should be a standard somewhere in the WordPress developer guide.

• This reply was modified 1 year, 10 months ago by obewanz.

@obewanz Thanks for the run-down.

I have just checked the code in the We’re Open! widget class and there are some aspects here that I would like to change (similar to my other plugin). This would make it more consistent with widgets in general.

I will go through a few things here over the week and include some changes in the next update.

If you have a free theme suggestion – I’ll check with this to ensure it’s sidebar/aside matches other Widget staples.

Very good… I have stumbled upon OnePress a few months back and found it to be an exceptional free theme. As is the case with most free themes these days, the paid version unlocks a lot of seemingly useful features, but it is not required to build an impressive website. They also take a unique (as far as I know) approach to adding those features by providing them in a plugin. I haven’t purchased the plugin yet – but I do intend to do so in the near future just to see how some of those features look and whether they really are worth the $50-$60 ish price tag.

One of my sites uses a Hemingway theme (which might be a fork as I remember having a lot of difficulty making it look not so amateurish) – but I plan to replace that theme with OnePress once I get a little more experience making the OnePress theme do things I want.

@obewanz I’ve installed the theme you suggested and also returned to one of the WordPress year themes… and you’re kind of right about the enclosures, but it is really inconsistent. The OnePress theme uses aside as a container and, TwentyNineteen uses section and TwentyTwentyThree doesn’t have any containers (and the We’re Open! widget is no longer supported).

I need to be really careful when making changes to the HTML structure – it could affect existing websites in unpredictably negative ways… if you’re expecting one element to be a child of another, this may be set in the CSS as such. Introducing any enclosing element could interfere with the styling. If I add something such as “Choose your enclosing HTML tag”, this will introduce more complexity to the relatively approachable widget (when compared to the Shortcode and its many parameters).

I will look into this a little more to see what consensus exists around this issue. Personally, if you’re using one of the newer themes, I would recommend using a HTML widget and placing a Shortcode into that… then you can enclose the Shortcode exactly as you wish (if any enclosure is needed).

If you have an article suggestion that covers the subject of enclosing tags, please drop me a message. Widgets seem to be going out of use in the newer themes and I may move away from this in upcoming major versions – using Gutenberg blocks and similar interfaces.

Thanks for looking into the issue, though I am beginning to feel as though this is an exercise in futility as you seem to not understand the point. Let me attempt to address your most recent response to this issue.

”?if you’re expecting one element to be a child of another, this may be set in the CSS as such.” <– This however is simply NOT true.

CSS is a presentation layer, and as such has no ability to make one element the child of another, it can only target existing elements as are output by the html generator or modified by some other method before output to the DOM. (If you can use CSS to target an element or id generated or modified by say javascript AFTER the DOM output is completed – I would love to see how you do that.) The point is, if a wrapping parent element is not included in the output – then there is NO HIERARCHY that can be targeted using the CSS to modify specific elements of the output, in this case the widget output, because any target to a class such as “widget_title” will target ALL “widget_titles”… but I repeat myself from the previous discussion.

Also, widgets are not going away – there is simply no way that a theme developer can write replacements for all of the popular widgets, let alone all of the potential widgets a site owner or administrator would want to deploy on their website – no matter what the theme developers want you to believe. And trying to wrap your widget into a theme under that premise would indeed be the end of your plugin – as stated previously – someone (if I’m not that person) would fork your existing plugin to fill that void.

In one last effort to help you visualize the issue – the following graphics and code are provided to illustrate how your widget appears to be different from other widgets that I currently use, because it is lacking a parent wrapping element and therefore cannot be customized by CSS beyond the hours table:

Customization of the widget (custom html) highlighted by the arrows (grey background with rounded corners) can only be achieved because the widget html output is wrapped in a uniquely identified wrapper element (html code will follow):

#custom_html-2 {
 background: #efefef;
 border-radius: 8px;
 padding: 5px; 
}

Moving to your widget specifically the only element that can be uniquely identified is the table output for hours:

/* CUSTOM OFFICE HOURS WIDGET STYLE CHANGES */
table.opening-hours-widget {
  border-collapse: separate;
  border-spacing: 0;
  border: 1px solid #ccc;
  -webkit-border-radius:7px;
  -moz-border-radius:7px;
  border-radius:7px;
  -webkit-box-shadow:3px 3px 6px -1px rgba(0,0,0,0.2);
  -moz-box-shadow:3px 3px 6px -1px rgba(0,0,0,0.2);
  box-shadow:3px 3px 6px -1px rgba(0,0,0,0.2);
}
.opening-hours .day-name {padding-inline-start:0.8em!important;}

Incidentally with CSS I cannot SPAN columns in your output table and therefore cannot add a footer that would equally span both columns for any purpose – such as to direct the user to a scheduler app/plugin to see where they might schedule an inspection, or for the construction company, an estimate.

Here is the html output that produces the above sidebar (cleaned up for brevity and illustration):

<div id="secondary" class="widget-area sidebar" role="complementary">

	<h2 class="widget-title">Business Hours</h2>
	<table class="opening-hours opening-hours-widget">
	<tbody><tr class="day monday past weekday">
		<th class="day-name">Monday</th>
		<td class="hours">9am – 5pm</td>
	</tr>
	<tr class="day sunday tomorrow future weekend closed">
		<th class="day-name">Sunday</th>
		<td class="hours">Closed</td>
	</tr>
	</tbody>
	</table>

		<aside id="recent-posts-2" class="widget widget_recent_entries">
		<h2 class="widget-title">Recent News</h2>
		<ul>
			<li>[CONTENT REMOVED]</li>
		</ul>
		</aside>

		<aside id="categories-2" class="widget widget_categories">
		<h2 class="widget-title">Article Categories</h2>
		<ul>
			<li class="cat-item cat-item-5">[CONTENT REMOVED]</li>
		</ul>
		</aside>
		
		<aside id="archives-2" class="widget widget_archive">
		<h2 class="widget-title">Archives</h2>
		<ul>
			<li>[CONTENT REMOVED]</li>
		</ul>
		</aside>

		<aside id="custom_html-2" class="widget_text widget widget_custom_html">
		<h2 class="widget-title">Trusted Area Professionals</h2>
		<div class="textwidget custom-html-widget">
			<p>[CONTENT REMOVED]</p>
		</div>
		</aside>
</div>

As you can see by the above code, if I want to target something specifically within the archives widget – I can use #archives-2 and then whatever element is available such as .widget-title to customize that specific element – the title of the Archives Widget… Your code output has no such specificity because it has no such wrapper element.

If I’m forced to go look into some standard to fix this issue with your plugin – then I might as well fork the plugin and fix it myself so I never have to worry about some future update breaking the functionality that I had to develop for the two websites that will be utilizing this type of feature. (Some of your comments above don’t give me <span style=”text-decoration: underline;”>warm fuzzies</span> that the future of this plugin is all that solid in the first place.) That said, I would still much rather YOU FIX the above illustrated issue so that I can move on with building these two websites, rather than being forced into coding for them.

@obewanz I’ll create a fix for this in the next release.

Apologies @obewanz.

It is a recently introduced error caused by applying the wp_kses() function. I will have a fix in the next release (1.45) which is coming either today or early next week.

Thanks! works like a charm.