« first day (2225 days earlier)      last day (1238 days later) » 

2:51 AM
This should be "solved" by dynamically generating images on demand, not buy making assumptions where images are used
7 hours later…
9:48 AM
generating images on demand comes with a risk of being an easy ddos button
1 hour later…
10:53 AM
@Rarst you'd appreciate this, Magic world cup :D twitch.tv/magic
hm? I don't care, hadn't played MtG in years. too expensive and inconvenient :)
I have NFI what they're even talking about its been that long
I play hearthstone since last year :) convenient online play, free/cheap
been meaning to check that out in all that free time i have
I use it to knock out webdev out of my brain
11:00 AM
Yeah everyone needs a good release... I watched a walk through on HS a while back, looks pretty good. Anyway just saw that MtG come up on the feed, remember you mentioned playing it.
2 hours later…
12:42 PM
@Rarst that is why god invented cache ;)
the problem is not cache... the problem is someone requesting 1x1, 1x2, 1x3, 1x4,... or 1 000 000 000 x 1 000 000 000... by the time you foolproof against all edge cases it's easier to make set of sizes and create them once
that is the simplistic option, a better one will be to still use the image sizes configured in WP, just generate them only when needed
then every request for missing image will still need to go through the logic of is it a valid image and such... WP's 404s are already ugly expensive operation :) WP way is lazy and storage costly, but it's robust
4 hours later…
4:23 PM
greetings oh masterful gods. . . how thee be on this day in time
Any idea why a singular pagination wouldn't allow you to navigate through all the published posts?
ehm, singular pagination? :)
4:42 PM
how is an archive that shows 1 post at a time different to just having a single post with previous and next post links?
much easier to skip things in archive query than next/previous mess?
5:07 PM
Like get_next_post(); && get_previous_post();
wow this is definitely irritating.
Not sure what you mean by your last statement Rarst.
print_r( get_previous_post() ); returns false or null. And there's definitely more posts.
Also confused by what you said Tom. lol
5:23 PM
@Rarst, actually when I thought about the idea a while back, the scheme was to generate the images when the API is called with the requested size, and not on explicit external request. This obviously has its own problems but should not open a DOS vector
ahaha..... Wow........ I figured it out.
Dumbest glitch ever.
Scribu had a different idea in one of the tickets to mark some sizes as "generated on upload" and the rest get dynamically generated
For some reason, some of these posts had the EXACT same publish date/time. So that was the problem. I simply just adjusted the "minute" to various times, and now the pagination works as expected. Can you believe that? I mean, it makes sense, but damn... That's stupid. hah
WP date/time, ugh :) just burnt some days on that again, was fun though
masochism? ;)
5:26 PM
nah, I got tired of remembering how to work around all the bugs so wrote a lib
release tweet above
yes, now I get the context for it
I don't see what's so wrong with just generating image sizes per Post Type or on a global level (like it currently is). So what happens when a Post Type requests an image size that doesn't exist? Simple solution. Fall back to the original full size image.
or just return false. either or, but I like the idea of returning SOMETHING. I'd gladly accept the full size image if the requested image size doesn't exist.
Because then plan B would be to take the full size image, and dynamically adjust the image size.
images are not associated with posts, they are their own post type. It just not related
5:32 PM
images are posts of type attachment, when an image is uploaded, a set of predefined sizes are created via resizing/cropping, these are defined by an array in PHP. add_image_size adds to said array, that's about the gist of it
okay but for example. I have a site right now... 20 different image sizes used all through out. But, let's just say I upload some photos to my portfolio. and my portfolio section, I only need to use 2-3 different image sizes for the uploaded photo. but for each portfolio photo I upload, there's 20 different image sizes being created. I only need to use 3 of the 20, so that leaves 17 extra images that are completely pointless and will never be used.
that will never work on a large number of setups
Why store pointless crap.
and it also opens up a new class of problems
e.g. how do we know which sizes are and aren't being used?
you'd need to pass all image requests through a PHP file slowing things down
because when you add your image size, you specify the post types you want to add this image size for.
5:34 PM
and if you setup rules to pass any 404 in the wp-content folder to the server, that's more load
and what if you can't create the image? Maybe it's a 40kx40k image and generating a medium size fails? Every page load is now going to trigger that resizing event
"because when you add your image size, you specify the post types you want to add this image size for."

This makes no sense, post types don't request image sizes
Why does it make no sense?
ok so when you blog.
because post types don't request image sizes
Let's use the default post type for example.
there is the original image, and then the image sizes specified
When you write your blog post and give it a featured image, do you do it through the media library? Or do you do it on the post editor screen?
5:36 PM
there's no part of that involving post types
that's an irrelevant question, featured images are stored as attachment IDs
they hold no information about the size
My point is
that's the themes responsibility
and even then, you don't know what a plugin might do, or if the theme changes
My point is, that image that you uploaded is intended to be used for the specific post object and likely no where else on the site.
then don't register the image size
or unregister the image size
that is noy how images in wordpress work
5:37 PM
It's a theming issue
images are global resources
a post type is a data structure
it isn't a template, and it has no knowledge of how it will be used
global resources, yes. correct. but like I said. You write a blog post, attach a featured image to your blog post. Are you going to use that image in your portfolio now too?
you're being imprecise with your language, which image?
you associate an image, not attach it
5:39 PM
You're likely only going to use that image within the scope of a specific post type.
but you don't know that
I've used featured images inside my post content in the past with differing dimensions
you don't know that
right... which leaves you with the default image sizes available that comes with core wordpress.
You have fallbacks.
but alllllllll of the custom image sizes added.
seems super redundant
ill never use those images, why clutter my uploads folder?
then don't register a custom image size you don't need
I can't control other plugins.
5:40 PM
other plugins have their reasons, and you have eyes and code review
I don't get how you don't see my view.
you know for your personal specific case what is and isn't necessary, but the code doesn't, your unique case would be considered too localised and closed as offtopic
There's crap being generated and stored that will NEVER be used.
you know that
the code doesn't
this is my discussion with rarst, the problem is the fact that image generation is not flexible, associating it with the wrong thing will just create additional problems instead of solving the core one
5:42 PM
and nobody can say what will happen in a years time
but in terms of making things more flexible, on demand generation is the only extra option available, and that's a major can of worms
okay so how is my argument for image sizes for specific post types any different than leaving it the way it is, then OVERRIDING all registered image sizes and removing them?
That's also creating extra work and opening another can of worms for problems by overriding intended functionality.
we'd now need to create all those image sizes, if anything we're in the same boat as before but with more image sizes, a greater support burden, and reduced compatibility. We've also introduced tight coupling between our data structures and our theme. Not to mention that any changes will require a lengthy regeneration of image sizes process
If you just specify in the FIRST PLACE that hey. These image sizes are only available in the scope of this post type.
That's the intended functionality.
I consider overriding the registered image sizes in that way a micro-optimisation
also consider if I have portrait image sizes for posts, and landscape sizes for pages
if I read this right, landscape sizes are only generated when an image is set on a page
You completely eliminate all problems by saying this image size can only be used in this post type or these post types. .... like... lol what? That's the intended functionality.
and you know that
that's something you know because that's how it was registered.
I mean, when you register the image size and you specify the allowed post types for this image size. Those are the rules. You're defining the laws right up front.
5:49 PM
it is the core design that images are independed, part of other bad core decisions
this opens up several problems:
- If I put the image inside one of my blogposts, it triggers an image resizing operation
- If I remove the image from my page it doesn't remove the now redundant landscape files
- If I upload an image in the media library without attaching it, none of these or all of these sizes are created
- This functionality instantly breaks on any plugin that uses the media_handle_sideload type functions
- Importing and exporting would need special cases to make sure that the images referenced also include references to the original image, with the content updates necessa
and a great number of other problems, there's a separation of concerns for a reason
not to mention that if the on demand generation fails, you can trigger it repeatedly to start a DOS attack
.... you don't have a separation between images that are content by themself and images that are part of other content (what you want to handle)
Who seriously uploads images to media library and then just leaves it there and doesn't attach it to a single post object ?
or even term object now
custom headers
sometimes comments
5:54 PM
Okay but .... widgets
and comments
also 3rd party integrations, REST API uses
could use the global image sizes
then we're back where we started
and you don't know what requirements those have
The requirements for each image size are specified when it's registered! You're saying this is available for.... everywhere..... or specifically for this type of object.
that doesn't prevent that image being used elsewhere
an attachment can be both a featured post thumbnail, a header, a panorama in a pages content, and a thumbnail in a widget, displayed full size in an app using the REST API somebody else wrote, etc
5:57 PM
So if a widget requests an image size that doesn't exist. It doesn't exist for a reason. It's not intended to be used in a widget. lol. It's intended to be used in a specific type of post object. NOT A WIDGET.
for your case yes, but in the general case somebody will want to be able to do that
for all cases. that's the whole point of creating this image size.
think about the image size being created.
Who's creating it?
What are they creating it for?
even then, it's still a performance nightmare, a major support burden, another hurdle for developers with numerous pitfalls, and a new attack vector
Why is it being created in the first place?
Where will the image size be used?
also, I have a plugin that registers a set of post types on a multisite, and 5 themes that rely on it, but all those themes have differing image requirements
if I put that data inside register_post_type I've now got a problem and need to adjust my data definition depending on which theme and site is being used, possibly based on which theme options are set
6:00 PM
Dont you remember school? Who? What? When? Why? Where?
if I use extra parameters on add_image_size, I now need to define data inside my theme, creating tight coupling
Just saying eveyrwhere for everyone in every case is just stupid. lol
it isn't, it's an effective and simple performance optimisation
It's lazy and creates no rules. It's a Free for All. Anything goes.
optimising for disk space is a significantly larger amount of work for little benefit in a world with unlimited storage plans
6:01 PM
Zero structure.
That's just a minimal point.
The main point is, why have redundant stuff?
Creates clutter and uses extra resources all across the board.
So think about this
firstly, your uploads folder is managed by WordPress, not you
secondly, those extra resources are negligible
Right now the way things are with Image Sizes. Anyone can do anything with any image anywhere in the site. There's no rules for that image.
thirdly, use a CDN if you're wanting on demand generation and efficiency
6:03 PM
It's like not having a government.
Why do we have governments?
Power? Control? Law and order?
that's not a valid analogy, images aren't people, they don't murder eachother, loot eachothers pixels and enslave eachother
You're a very hard person to persuade Tom. lol
I get your point, I simply disagree with it, it's a tradeoff
adding more rules might let you optimise disk space and be more precise about certain things, such as where images can be used and what sizes they're created in
but that adds constraints, which while helpful for some, are obstacles for others
Why would it be an obstacle for anyone?
Because you don't agree with the rules?
That's the way it is. Accept it.
there's nothing preventing you from adding a taxonomy to attachment images and using that to filter what's shown for certain places, or deleting image sizes on a cron job after running through content to see if they're used
6:07 PM
If you don't like the rules, why don't you add your own custom image size?
sometimes I do add my own custom image sizes
but only if I feel it's necessary and optimal
and we do have basic rules, we have mime types, authors, and a data framework to implement rules on top of as we see fit
but those rules would need to fit in with 27% of the internet
okay but lets go back to square 1
answer this for me.
Image is uploaded. Multiple image sizes are created based on this uploaded image.

Consider this:

- Who is specifying the need for this image size?
- What is this image size going to be used for?
- When will this image size be used?
- Why will this image size be useful?
- Where will this image size be used?
- Who is specifying the need for this image size?
The person who wrote the code adding it
- What is this image size going to be used for?
Core doesn't know that, and it's not such a simple question to answer, but the person who added the image size knows
- When will this image size be used?
The developer might have a use case idea, but nobody can be certain, afterall I might add an image size for a particular use, only to find my users really like the way it looks right aligned in a post
- Why will this image size be useful?
Okay so now think about this.
Who/what provides the information available? The theme or the plugin?
The plugin defines the data
the theme can add an image size if necessary, but that isn't modifying the data structure
6:22 PM
The plugin author says, "hey theme. Here's what I have for you."

The them author responds by saying, "Hey plugin, You don't have what I'm looking for, can you get me this as well please? "
it's like ordering food from a restuarant
** adds image size **
the current system is customers needing mushroom free carbonara because they'll have a reaction and get sent to hospital if they don't
whereas what you're proposing would change the menu itself
That's the workflow of a website. Come on you know this. Theme's don't call the shots.
images are individual pieces of content, represented by posts of type attachment
6:23 PM
Plugins are superior.
add_image_size adds more content, but it doesn't change the data structure
attachment posts are the data structure
So if a plugin doesn't want this image size used anywhere else, that's the deal.
If you don't like it, then create your own.
So you can use yours where you need it.
or use something close and adjust accordingly, be flexible
k so now let's look @ attachments.
There's an attachment object stored in the database as technically a "post". Then there's information about each attachment stored in the database technically as "meta". Then there's all the actual image files in the uploads directory.
So why is it such a crime to control the files in the uploads directory?
You're not changing the object in the database.
The original object which represents the image stays the same.
So how are you changing the data structure?
The information about each image remains the same.
and it's still controlled the same way.
7:02 PM
I think the biggest problem with image sizes "attached" to post types is that the global media library allows you to pick and upload images on the fly, not necessarily "attaching" them to a specific post type.

To circumvent this, on our hosted websites we don't really allow a global media library but a post specific media library where the user only sees images that are uploaded to that post. Then those images are also deleted whenever the post is permanently deleted. In the end, it allows up to easily assign images to the post type since there's no disconnect.
TL;DR I think the global media library is probably the big hurdle when dealing with the post type images and the whole issue is probably plugin territory.
3 hours later…
10:13 PM
image system in core is broken, for example what is the featured image of an image? It is one of the areas that need a rethinking and rethinking is not core developers best quality (whether the reasons for that are good or bad makes no difference as the end result is stagnation in a bad state) </rant>

« first day (2225 days earlier)      last day (1238 days later) »