Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image generation rewrite: back to basics #403

Closed
sybrew opened this issue Jan 11, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@sybrew
Copy link
Owner

commented Jan 11, 2019

" Normal people don't understand this concept; they believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet. - Scott Adams

Related:

  • #166, this is the 4th post in the series.
  • #395, this will fix it.
  • #110, this is a prerequisite.
  • #268, this will allow it.

The image generation code stems from an early release, 2.0.5, and was improved further in 2.5.0. Over time, I've combobulated integration for Open Graph image dimensions, AJAX uploading, WooCommerce gallery support, and more. This lead to an inconsistent system that's all over the place; some might call it spaghetti code, and they'd be right.

This is what we're going to do:

  1. Standardize callers.
  2. Deprecate all old callers.
  3. Rewrite the generation code.
    • Synchronize it with WordPress' API, which improved its image handling significantly in the past two years.
  4. Upgrade all attached systems (social meta output, extensions, etcetera).
  5. Add more features.

I'm a user, what can I expect?

Fewer (goal: zero) bugs, faster operation, and more features!

I'm a developer, what can I expect?

I'll deprecate all related methods and make all attached filters inoperable under normal conditions.
Your implementations won't break, but warnings will be shown.

A full list API of changes will follow.

In 3.5 or 3.6 I'll remove the deprecated code. You don't have to worry about updating: Your site won't crash when calling undefined methods, because the factory (the_seo_framework()) has fail-safes.

@joshuafredrickson

This comment was marked as off-topic.

Copy link

commented Feb 27, 2019

I'm not sure if this is included yet, but I've come across an issue when using an og:image on a CDN. The upload URL is prepended to the image's full URL.

Instead of https://cdn.example.com/og-image.jpg, it returns https://wordpress-site.com/wp-content/uploadshttps://cdn.example.com/og-image.jpg.

I believe this is related to the resizing process found in parse_og_image().

@sybrew

This comment was marked as off-topic.

Copy link
Owner Author

commented Feb 27, 2019

Hi @joshuafredrickson

This isn't the right place for support. Please refer to our support forum in the future.

In any case, the bug you're encountering is caused by the CDN rewrite plugin active on your website. You should contact the authors of that plugin.

@sybrew

This comment has been minimized.

Copy link
Owner Author

commented Apr 20, 2019

We want to consider adding filters to (all) the image selections. I do have to check if the IDs of the images are independent of the size.

Ref: Inje's support inquiry on w.org.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.