• As I already wrote this feature would fit well into Media File Renamer as a “one stop plugin for handling all media filename & metadata operations”.

    My preliminary research had shown:

    1. It can sync media title changes to the ALT text in the Media Library.
    2. It can not sync to the ALT tag in existing HTML markup.
    3. On the other side it definitely has the capability to sync media metadata changes to existing HTML markup, e.g. it can update filename references in the SRC tag.

    So it’s feasible: What works for the SRC tag certainly will also work for the ALT tag. A matter of implementation.

    • My primary reason to buy Pro would be an option to keep Mixed Case filenames when changing the title with sync on.
    • This feature would be my second most important reason to buy Pro. Not by itself as there are other plugins for this.
    • But having these two feats combined would make it my single media metadata plugin certainly!

    🙂 Hoping to get an answer this time!

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Jordy Meow

    (@tigroumeow)

    Hi,

    Haha, I know… I replied 😉 Sorry about this.

    My primary reason to buy Pro would be an option to keep Mixed Case filenames when changing the title with sync on.

    I think I mentioned it before, but I do not want to do this. In fact, nobody ever asked for it, it would increase the complexity of the code by too much (I know it seems small, but it isn’t, based on how I build it), and more importantly, it would cause numerous issues, mainly:

    1. Inconsistency Across Platforms: Different operating systems and servers treat filenames differently. Unix-based systems (like Linux or MacOS) are case-sensitive, while Windows is not. This means that ‘FileName’ and ‘filename’ would be considered the same file on Windows, but different files on Unix. This can cause issues if your website or application is moved between different systems.
    2. SEO considerations: Lowercase URLs are generally preferred for SEO purposes as search engines can potentially treat URLs with the same path but different cases as duplicate content, which can impact your site’s SEO performance.

    There is also a big difference between how the static files are interpreted by the HTTP server and how they are interpreted by PHP and/or the system they are on. It could be an absolute nightmare, and I actually went through it many times in the past. Hence that limitation. Sorry, but I can’t add that option, otherwise other users will enable it thinking that it could be nice, and it would break installs.

    It can not sync to the ALT tag in existing HTML markup.

    That’s another difficult one; the HTML markup is generated by page-builders generally. In simple cases, it could work, but in a lot of cases, it would be very difficult and I would need to develop parsers for every plugin and page builders that use images, so update the ALT at the right place, or to trigger a reset of their internal caching system. I could add this feature in its simple form, and that would form for post that are written in simple ways (Gutenberg Blocks), but otherwise, it wouldn’t. I am afraid to open the doors to a huge lot of additional issues. I prefer to keep things simple and operational, and to say sometimes no even though; this is what developing plugins for 10y taught me 🙂

    You can definitely use the filters I have built inside the plugin to do what you want though, you could try. You could even hire a developer to try to hack into this. You can make it work for your specific use cases. For me, implementing it in the core plugin, I would need to make sure it work for most cases, and that’s a huge challenge.

    Thread Starter abitofmind

    (@abitofmind)

    Thanks for this very good answer which states the reasons behind!

    If you want to be a product-driven and not a customer-driven company it’s important to say NO and stay true to the product vision or else you’ll get bloated software products in the long run! Totally d’accord with you!

    I) Replacing ALT tags in HTML: Yes ofc this only has to support images inserted with standard compliant image blocks. Are you willing to offer this?

    II) MixedCase:

    a) Good that you told me about further the issues which can come up the long way besides webhosting and filesystems! I did not yet go live with my website, and the spiders have yet not indexed my media files. So another chance to revise my decision. From my setup alone it works fine. But given the possibility of CDNs, reverse proxies etc, I can imagine ever further potential nightmares “later in the delivery pipe”.

    a1) Possibility that users can download media with nice filenames: No valid reason on its own. To support this (if at all) I could offer a download link which gets constructed from the media title so main-topic-sub-topic-remark-on-variation.jpg offers a download link which will end in a file download of Main topic - Sub topic - Remark on variation.jpg.

    a2) And thanks for telling me that you offer the possibility for filters, so a hired WordPress/PHP dev could bake my MixedCase preservation into it. Only remaining question: Your function “Rollback to Original” would also work in interplay with those filters correctly? B/c as the plugin is now capitalization is NOT restored on rollback.

    b) If I use lowercase only and still want to achieve somehow good human readability my idea would be that in addition to - (minus) as the universal word separator (which replaces spaces and punctuation) I use -- (two minus characters) to separate topical clusters main-topic--sub-topic--remark-on-variation.jpg. For this all it would need in the plugin settings would be string replacement options, similar to the transliteration replacements. - (space minus space) gets -- (two minus characters) and any space and punctuation gets -.

    Update: This customization should be easily possible with filters which offer full PHP and its RegEx functions. As I understand it it should work with “Rollback to Original”, because it stores $old and $new and the $post ID too.

    • This reply was modified 2 years, 11 months ago by abitofmind. Reason: Realized that custom transformation like " - " to "--" should be possible with the filters
    Thread Starter abitofmind

    (@abitofmind)

    Looked into the source code (with my layman coding capabilities, enough to get a rough feasibility estimation at least). As I see it my custom hyphen replacement wish could get a bit hard.

    You have a dedicated format_hyphens() function and a replace_chars() function. As I do not know the execution order of all these, a simple filter may not work as expected. Maybe I need to replace with multiple filter passes. Early on - to something unique like XXX and then after all the normal punctuation and hyphen replacements went through (dangerously to my endeavor are those which handle consecutive hyphens!) run my final filter which replaces then replace XXX to -- .

    Before I hire someone, I ask you who knows your architecture: Is your filter architecture capable of this (especially regarding the processing order) ? Do these filters get complete filename responsibility (and call the sanitations/hyphen-normalizations when I deem fit in my processing order), or are sanitations/hyphen-normalizations run hardcoded before/after all the user filters?

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Syncing media title changes to ALT text also in existing HTML markup’ is closed to new replies.