ajwe

Here’s something I just tried that seems to have worked:

I fired up phpMyAdmin, found the record in wp_posts where post_title is Custom Styles and post_name is wp-global-styles-twentytwentyfour and post_status is publish (not inherit). Then I copied the post_content field, pasted it into vscode & re-formatted the json, then deleted the parts of the json where it mentioned Jost & Inter, then copied & pasted it back into the database record to replace the post_content. When I reloaded some pages, all the references to Jost & Iter are now gone.

Probably not the safest thing to do in the world, and this was only on my test site which I can mess up if I need to, but it worked!

Hi Kavya @properlypurple,

I did try the Create Block Theme plugin after seeing that recommended in another thread. I installed it on my test website & went to the Appearance -> Manage Theme Fonts section and removed everything other than the System Sans-Serif & System Serif fonts, and then reloaded some pages on my test site. But, it still seems to have the Jost & Inter font faces loaded (there’s no caching on my test site, so that shouldn’t be an issue).

So I figured just removing the fonts wasn’t enough. I tried saving the changes as a style variation (not quite sure what that actually means, as my mental model of themes seems to be off a bit). But, it didn’t work, and instead it seems to have reverted my website back to all the default stylings (e.g., images got rounded corners again) and was a mess. But I was able to use the timeline to revert back to the previous state.

I tried the Clone Twenty Twenty-Four option to create a theme ajwe-2024a, then uploaded that back to the server & activated the theme, but the source code still shows @font-face calls for Inter & Jost.

Finally, I tried the Create child of Twenty Twenty-Four option to create a theme ajwe-2024c, uploaded it to the server & activated the theme, but it still is showing the @font-face calls for Inter & Jost.

I must be doing something wrong here and probably don’t understand some key concept of how the themes are storing style changes (database vs. json vs. ???), or how the theme decides to emit the <style id='wp-fonts-local'> section with these font-face references.

When I visit the modified themes/twentytwentyfour directory and grep for Jost in the theme.json file, it’s not there. So something else must be causing this code to get inserted… ?? I notice in the database, the wp_posts table has a record (last updated this morning, so it must be related to these experiments) with post_title “Custom Styles” that has a bunch of json with references to Jost & Inter in the Typography section, even though those aren’t listed under the Manage Theme Fonts section of Generate Block Theme plugin.

Thanks @jordesign for your reply. Hmm, I just started playing around with this on the dev site to see what it does. One thing that worries me is their disclaimer about not using it on a production site (I don’t want to risk it mucking everything up if I push the copied theme live). But, also, do you know what would happen if TwentyTwentyFour has an update? Would that overwrite the styles in the exported theme? Or, if I exported the theme as a child or new theme, then managing things going forward seems like it becomes more complicated.

Ah, thanks for this information. I tried looking around to see if this was a known issue but I must have been looking in the wrong places. Appreciate the pointer & the workaround.

Because it might be hard to see what I’m describing, I created a clean install of WordPress that uses Twenty Twenty Four and was able to reproduce the issue. It turns out the dropdown menu needs to have a background color in order for the issue to show up. The attached image shows two different pages, one with a bullet list and one without, and how that manifests as the dropdown menu on one having messed up padding.

Hi @properlypurple! It looks like that did the trick, and it seems that this feature is supported on all modern browsers (anyone still using IE can deal without the drop shadow! ?? ).

Thanks so much, Kavya, for digging into this!!! I’m not sure I’d have ever found the solution.

Hi @properlypurple Kavya,

If I make Aspect Ratio “Square” and leave the Scale set to “Contain”, then the problem remains the same. The shadows are around the square box but the image is rectangular within the box.

If I make the Aspect Ratio “Square” and change the Scale to “Cover”, then the image fills the square and the shadow matches the image, but then I’m not showing the whole image at its actual shape, which is very important for my application (displaying artwork thumbnails, where customers need to see the shape of the art). (Setting Scale to “Fill” is worse, as it stretches the image to fit a square.)

The HTML is slightly different by setting Aspect Ratio to “Square”:

<div class="wp-block-column is-vertically-aligned-center is-layout-flow wp-block-column-is-layout-flow" style="flex-basis:25%"><figure style="aspect-ratio:1;width:200px;height:200px;" class="dropshadow wp-block-post-featured-image">
<a href="..." target="_self"  style="height:200px"><img fetchpriority="high" decoding="async" width="300" height="226" src="...-300x226.jpg" class="attachment-medium size-medium wp-post-image" alt="..." style="width:100%;height:100%;object-fit:contain;" srcset="...-300x226.jpg 300w, ...-1024x770.jpg 1024w, ...-200x150.jpg 200w, ...-768x577.jpg 768w, ....jpg 1200w" sizes="(max-width: 300px) 100vw, 300px" /></a></figure></div>

I’m not certain, but in playing around with a bunch of things on the codepen site, it seems to me that the issue may be that WordPress is writing out width="300" height="226" (the physical size of the image it’s loading) in the img tag, even though that’s not the final size the image is rendered as.

I think I’ve narrowed the issue. It seems to be the following:
style="height:200px;object-fit:contain;"

that is causing the issue. This is appearing because I have the attributes on the Featured Image set to: Original aspect ratio, width 200px, height 200px, scale Contain.

And just as a reminder, what I have here is featured images that are either square or portrait (rectangle) or landscape (rectangle) and I want them to fit within a fixed size (200×200, say) so that they’ll all line up neatly on the page, but have the dropshadow just apply to the img.

See this codepen example, if you remove the style snippet the shadow seems to be applied properly (but I don’t know if that’s necessary for the proper scaling to work).

Hi @properlypurple Kavya, thanks for the reply. Unfortunately, it doesn’t seem to have made any difference (& I checked the HTML to make sure the new style was there). Here’s what the generated HTML looks like for one of the images (I’ve replaced the filenames to my local site with ‘…’).

<div class="wp-block-column is-vertically-aligned-center is-layout-flow wp-block-column-is-layout-flow" style="flex-basis:25%">
<figure style="width:200px;height:200px;" class="dropshadow wp-block-post-featured-image">
<a href="..." target="_self"  style="height:200px">
<img fetchpriority="high" decoding="async" width="1200" height="902" src="..." class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="..." style="height:200px;object-fit:contain;" srcset="....jpg 1200w, ...-300x226.jpg 300w, ...-1024x770.jpg 1024w, ...-200x150.jpg 200w, ...-768x577.jpg 768w" sizes="(max-width: 1200px) 100vw, 1200px" />
</a>
</figure>
</div>

I suspect the issue is something simple like you suggested; the class “dropshadow” is applied to the <figure> tag if you put it on the Featured Image block, so how do I get it to apply just to that img? I’ve tried a bunch of combinations & tried exploring in Chrome’s “inspector” but my CSS is rather rusty. (In this example, I had the “resolution” set to full, but even if I change it to “medium”, which is more appropriate for the small images, there’s no change.)

• This reply was modified 1 year, 2 months ago by ajwe.

Hi Felipe,

Thanks for the reply. My site isn’t live so I don’t have a link. I’ve currently gotten around this problem by not constraining the size of the featured images, and that fixes the dropshadow issue but isn’t quite the design I’d like.

So, more details. I created a Test Page to recreate the issue (see image below, my actual post images are blurred out into colored blocks). There are two featured images, one that is in landscape orientation and another that is in portrait orientation. I’d like all of the images to be constrained to a max of 200×200 pixels (most of my featured images are square, but these two aren’t), so the featured image block is styled to have Original Aspect Ratio with W=200px and H=200px and Scale=Contain. I want the dropshadow only around the image portion. Also, I don’t want *all* featured images on the entire site to have this shadow, only those within a few specific query loops on the site.

To get the dropshadow, I added a dropshadow class in the ADDITIONAL CSS CLASS(ES) field when styling the specific Featured Image block in my query loop, and in the site’s Styles -> CSS -> Additional CSS section, I have the following:

.dropshadow {
	box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
}

But it seems that the class gets attached to the <figure> tag in the HTML rather than the <img>, and when the image isn’t square you get this result.

So, how do I target just the img in a figure in only those Featured Images within certain query loops on my site?

Thanks!

OK, thanks, I see why that fixes it (strtoupper). I’ve made the change manually for now and that does resolve the SQL issue in the error log. I do have to make sure the DATE FORMAT field is explicitly set to Y-m-d; for some reason when I blank that field out (which should pick the default), it goes back to finding no results.

(I do still have one other strange issue now: If I set the date to “now” or “tomorrow” or “yesterday” or “2023-12-27” or even “today UTC” it works, but when I set the date to “today” it returns no results. Very confusing, even though when I use php interactively it seems fine. At least I can work around this for the moment by just using “now”.)

Yeah, I was looking through the part of the plugin code that handles the meta query to see if I could figure out what I might be doing wrong and it all made sense (though I am no php expert). I ran php in interactive mode and it does the right thing:

php > echo date('Y-m-d', strtotime('today'));
2023-12-27

But after viewing the web page in the browser, I see the following error appear in the apache error.log (this is just a snippet):

WordPress database error Incorrect DATE value: 'today' for query \n\t\t\t\t\tSELECT SQL_CALC_FOUND_ROWS  awp_posts.ID\n\t\t\t\t\tFROM awp_posts  INNER JOIN awp_postmeta ON ( awp_posts.ID = awp_postmeta.post_id )\n\t\t\t\t\tWHERE 1=1  AND ( \n  ( awp_postmeta.meta_key = 'end_date' AND CAST(awp_postmeta.meta_value AS DATE) >= 'today' 

So somehow it seems that the strtotime() call isn’t happening, as ‘today’ is making it all the way to the SQL call. Hmmm. ??

Hi Phi, I do have the data type set as Date. I don’t have a convenient place to upload a screen shot, but the fields are set as: Data Type: Date, Compare Operator: >=, Date Format: (blank, but I’ve also tried explicitly setting it to Y-m-d), Field Key: end_date (my custom field name, which is stored in the Y-m-d format), and Field Value: today (I’ve also tried “now” & various other options; it only works if I explicitly set it to a value like 2023-12-26).

If I set the Field Value manually to 2023-12-26, immediately in the block editor the two matching posts show up (and show up if I save the page & view it in a separate browser). If I set the Field Value to “today” (with or without the quotes), the posts disappear.

I’m using WordPress 6.4.2 and the php version is 8.1.2-1ubuntu2.14.

Ah, thanks so much! I had never noticed that option (D’oh!) and that did the trick.

I don’t know if this will help, but I had a similar issue and couldn’t figure out how to cleanly get custom post type fields into the query loop of an archives page for that custom post type. Here’s what worked for me:

Within the Query Loop block, add an HTML block. Now, within that HTML block, you can add the rather ugly looking HTML necessary to pull out fields. For instance, I have a section that looks like:

Venue: <!-- wp:pods/pods-block-field {"field":"venue"} /--><br/>

This makes it not too hard to get a nicely formatted paragraph of text interspersed with custom post type fields. Why am I doing it this way? Using the Pods Field Block was very hard for me to figure out when you want the fields interspersed with text. Also, whenever I tried using short codes or magic tags (e.g., {@venue}), it never seemed to pull any information. Also, by using the HTML block, I don’t have to switch into the code editor, because if you do that and then switch back to the visual editor, much of your custom HTML seems to get wiped out. Hope that’s helpful!