Tom J Nowell

Specifically, it's caching oembeds of your posts, not oembeds your posts use. So think less stuff like youtube etc that get pulled into your posts, but rather your posts themselves when 3rd parties try to embed them into their site

this might be the closest thing WP has to a built in fullpage cache since that's the entire output of the oembed endpoint

@ChristineCooper how is oembed creating any rows to begin with?!

I've no idea, the whole thing is a bit sloppy and disorganised unless you follow all off Matts socials holistically

some suspect heaqding off regulatory or legal involvement

ooh, yeah he tweeted about it, he's unblocked everyone on X and someone asked about unblocking from wp.org

@MarkKaplun previous which?

as he's already using an option that'd be autoloaded but at least it'd expire

you also get devs trying to be clever and doing things like fetching only the post IDs to try and save bandwidth and CPU, then doing get_post on each one, not realising that this creates lots of tiny back and forth fetches to the database and that WP was going to fetch them all at once to save CPU and prime caches in the first place

generally, and something that happens a lot when tools such as ACF are in use, is that devs have lots of queries with meta_query, or use parameters such as __not_int or NOT, or even worse ordering by RAND which can all be super heavy on the database and spike CPU

how are you measuring things? Have you got a tool like the query monitor plugin running to show timings and exactly which queries are slow?

especially if you have an object cache, that means the post query to fetch it is already being cached

though I still think that for something as simple as asking the DB for 1 post from a year ago this is massively overcomplicated, and runs the risk of slowing your site down a little bit rather than speeding it up

caching the post ID would be safer, more efficient, and avoid escaping issues, as well as eliminating the need for output buffering and other things

also your echo $thefield needs escaping, I know you stored some HTML in that option using code that you wrote but what if it was something else? What if it actually contained <script>alert("buy crypto here");</script> or something malicious? I'd also be mindful of what it is you're caching, HTML is super easy and cheap to generate, it's figuring out what the data is that's expensive, aka which post was 1 year ago, so you'd be much better off storing a post ID instead

if you're referring to a system cron job that directly hits the PHP file containing your code then yes there will be issues running WP functions as WP is not bootstrapped. But this is not a problem as it requires you to do a really really insecure and stupid thing before you run into this problem ( making direct requests to PHP files in a theme or plugin )

if you're referring to a WP Cron aka a function hooked to an action that's then scheduled to run at a certain point then there should be no difference

I'm not sure what this means or where you read this, do you have details? And what do youmean by fire the script via cron when it is in a one off plugin?

> I read that files can't be accessed directly in plugins by cron.

@BlueDogRanch are you sure that this is the bottleneck of your site? I'm surprised if this yields meaningful performance improvements, especially if you have an object cache configured

I think it's a micro-optimisation, fallback can be done by asking for the first 5 posts after a date and using the first avoiding multiple queries

especially since the post date is an indexed column, so this will be a faster query than most

instead it's easier to just ask WP_Query, and if there's an object cache modern WP will cache the result, and when the day changes it'll be a new query to cache

by ignoring the usual standard loop and going straight to ->posts you bypass all the lifecycle hooks that occur, and you bypass any lazy loading that's in place on posts

@Howdy_McGee it's put in cache regardless when WP_Query does its thing and primes stuff, eitherway, and the answers don't include any logic to double check that post meta is out of date or not. Ignoring that the post that was 1 year ago can be multiple things depending on the timezone of the person

have_posts() is enough to check if posts were found, there's no need to check the SQL or dump ->posts

because the_title doesn't return the title, it prints it, so echo has nothing to work with and prints nothing

and echo the_title(); is the same as echo ""; the_title();

Also you don't need setup_postdata and wp_reset_postdata if you use get_the_title( $post_id ); instead

@BlueDogRanch you do realise the moment it strikes midnight that ACF field will be wrong. I'd avoid foreach( $query->posts as $post ) { and setup_postdata when you already had the better solution to start with of a standard query loop. I also see a common mistake of pulling variables out of thin air and trying to use them

as of yet, the only person who's announced forks in response to Matt is Matt himself

if nonce expiration < cache expiration then the issue is to be expected

tbh the strict answer there is probably a hard no

if you do not have a need for attachment pages, as most people don't, then turning them off is wise, for many reasons

@MarkKaplun no, that's not the case

@MarkKaplun that's a logical leap

@MarkKaplun this is a matter of opinion, there are situations where they are quite useful, though you'll be glad to know core turns them off by default now

again that's not really the root problem, it's an X Y problem

is the obvious solution there if you want to break back-compat to separate attachments into their own table?

that heavily implies you're searching for posts via their post meta values

the only thing I can see is the premise that it reduces the size of the posts table therefore it would speed things up

yup, without GD or imagick it's incapable of resizing the images to create the sizes

what about other image sizes, e.g. those from core? If it's just your custom size missing then that's a problem, but if it's all non-original sizes missing then that's a larger issue. Have you confirmed site health check is working fine and no PHP extensions/modules are missing such as GD or Imagick?

In your code you're not using the after_theme_setup hook, the add_image_size call is happening after the closing } of the function so it happens at the top level immediately. You'll want to fix this, regen images, then confirm that an appropriate image file was generated in the filesystem ( ignoring WordPress and the browser ). Once you've seen directly that file with those dimensions and cropping in the filesystem ( FTP/CPanel/SSH/etc ) then you can proceed to the next step, but right now I think it doesn't work because the image size is not present or registered

Also add_action('after_setup_theme', '$name') is very unusual, are you trying to insert a function name dynamically or is this just an example? For that hook to work you would need function $name(... which isn't possible and would generate a syntax error. If $name holds the name of the function to be called then you can't wrap it in quotes. please expand the code section you shared from functions.php to include the function,it's name, and it's add_action hook rather than just the add_image_size, I've a suspicion your image size never existed in the first place

The URL you shared as coming from the src value heavily implies that it's using the original unmodified full version of the image. This usually suggests that the image size you created has not been registered with the same name as what you requested, or that it was added after the image was uploaded and the thumbnails etc need regenerating

I mean the actual HTML tags e.g. <img ... etc, in the final output as the browser sees it, though the PHP code that generates it also helpful. The image file itself is irrelevant and has little to no impact on the problem. As for how to check this without a gallery, a simple image block would suffice, it would let me see both the URL it chose as well as the sizes and srcset attributes

Also, you did not mention in your question that you were using the images in a gallery, this is important information, please eliminate the gallery during testing, we want the simplest most straightforward test/check with no unexpected surprises to confound/complicate things. Also, can you share the HTML rather than describing it?

None of my questions were about the media library. When an image is uploaded a post of type attachment is created in the database and that is what is listed in the media library, not the files. WordPress on upload puts the original file in place aka the "full" size, then creates all the additional image sizes that were defined as new files, with their dimensions in the filename. That is what I was asking about. Instead of looking in the browser and viewing the image on the page to see if it's what you expected it to be, look at the HTML tags and share them, and the actual file directly

have you checked the markup is using the actual image you wanted to? And that the image size leads to a URL with what you wanted? Keep in mind this might all get bypassed if you're using plugins or CDNs to dynamically generate images on the fly, e.g. Jetpacks photon etc