alt text length

@avisato, thank you for reaching out. I do not recall specifically truncating alt text length and edit, but I will investigate. There would not be a setting to disable that.

How long of an alt text are we talking about? I will need to replicate the issue on my end so that I can fix it.

Thanks

-Steven

@avisato, the actual alt text value is not being truncated as the full value is being stored into the database. It appears that the textarea field is truncating the value to 256 characters after retrieving it from the database. If you were to save it a second time, it would actually be truncated.

I’ll have to investigate further to determine a fix. I will remove any length restrictions that I find and let you know when the bug is fixed and a new version is available.

-Steven

thanks. the site i’m using it on is storing a lot of social media posts with text in them and it’s useful for screen readers to have the whole text in the alt tag for accessibility. in some cases, definitely more than a thousand characters. i looked through all the code after posting and couldn’t find any truncation so i’m confused where that’s happening. when it gets it back from the ajax, it seems to be truncated in the table even before it goes to a textarea. if i set it in the page editor, it can be very long but, if i set it in the plugin, it isn’t storing the whole text even the first time, though looking through what’s happening i can’t see where it’s getting chopped off. i have tens of thousands of images to get through so my use-case is just having an ocr extension, open the graphic, select the text, paste it into the box and save. i wish there was an automated fix but that’s the best i can come up with. but i can’t seem to make it save the whole thing yet.

@avisato the custom database table for Fix Alt Text has a limit of 256 characters. This table is used to reference what the values are for an image quickly without conducting a scan (heavy process). This location of the alt text is not the actual location; it’s only an index. When we retrieve the data from the custom table, it is truncated. When you paste more than 256 characters in the textarea, the image alt text gets updated with the full-length value and the index entries get cleared out of the custom table, then the post where the image is located is rescanned by the plugin. During the rescan, the custom table gets repopulated and the alt text gets truncated when stored back into the custom table.

The only time the alt text gets truncated is on view in the admin in the preview and in the textarea when editing. This means that if you were to past 1000 characters into the textarea and save, then 1000 characters would replace the real alt text, but when you click edit inline again, the 256 characters would be shown in the textarea this round. Of course if you hit save again without correcting it, it would truncate it for real that time.

What ocr extension are you using? It would be nice to be able to implement a fix that can speed up that process for you.

Solution:

1. Increase character limit – Change the length of the custom table to allow a higher limit and put in some protections to prevent someone from placing a large amount of text, causing memory issues on retrieval.
2. Custom setting – Add a settings option that will allow you to change the issue “text too long” value from 150 to whatever you like so that you are not harassed by the plugin for your intentionally longer alt texts.

I will work on fixing this and notify you when the new version is available for download.

-Steven

that makes sense. i hadn’t looked at the table structure when i was searching for the source of the truncation.

because of the nature of a lot of social media content, all the text ends up as graphics. would be so much nicer if you could upload pdf files to instagram but alas…

i haven’t found an ocr extension that allows me to batch the process so the way i’ve been doing it has been to use the builtin safari ocr, which is quite good. the worst part is actually that wordpress doesn’t allow for automatic stripping of newline characters so you end up with a bunch of linebreaks in the html it generates instead of changing those newlines to spaces. yes, the alt tag theoretically allows linebreaks but lots of stuff in wordpress breaks if there are any in there, i’ve discovered.

We are testing the new version and have fixed the bug and added some new features in response to your support request. We expect to release version 1.8.0 on Friday. I’ll update this thread when it is ready.

-Steven

@avisato,

We appreciate your patience. We have released version 1.8.0, which should resolve your issues. If you have any further issues, please let us know as these types of feedback and support requests are what makes this plugin better with each new version we release.

Also, if you like our plugin, please give us a positive review. ??

-Steven

@avisato,

I forgot to mention that we added some new cool features:

1. Ability to turn off/on specific issues that the scan detects
2. Ability to dictate the maximum character length for alt text within settings
3. Ability to dictate the minimum number of words for alt text within settings

-Steven

• This reply was modified 3 months, 1 week ago by Steven Ayers.

that sounds fantastic! i’ll update it on that site and give it a shot.

looks great. thanks for fixing that up. one other thing that’s popped up. not sure if this was happening before because i didn’t look. escape characters aren’t being filtered out when it loads the alt tag back into the editor. i’ll give an example. let’s say i type in this…

she’s going to the movies to see “star wars” tomorrow.

it saves that as…

she\’s going to the movies to see \”star wars\” tomorrow.

so far so good. when it grabs that back into the table, it doesn’t filter the escape out so it appears in the textarea as…

she\’s going to the movies to see \”star wars\” tomorrow.

then, when it’s saved again, it saves it as…

she\\\’s going to the movies to see \\\”star wars\\\” tomorrow.

and this loop would continue.

not a massive disaster for my purposes because the point is to try to enter the data, not to go back and edit it over and over. but i thought i’d point it out while i was noticing it.

while it’s on my mind, i was wondering if you had thought about adding an option that lets you load all alt text, not just the ones with errors, into the editing table. at the moment, you can only edit the ones that are missing it or triggering a length error but it would be great to be able to skim through all the alt text to proof them for issues in the same way. that would really only be functional if there was a way not to truncate it in the table, i guess — at the moment, it truncates the table display to 255.

i’m working on a way to batch-ocr content into the textareas but i haven’t found a way to successfully do that yet. being able to do them all on one screen thanks to this plugin, though, is fantastic!

thanks for putting this all together.

@avisato,

You get a gold star for finding bugs! I will investigate that issue and certainly get it fixed!

Displaying All Rows In A Single Table View (no pagination)

At the moment, we can’t display all rows on the table at once. Due to memory issues, we limit this to 100 per page (25 by default). Due to the size of the content you are playing with, you are certainly going to experience running out of memory fatal errors. The issue would happen when retrieving the database.

Edit “Alt Text” With No Errors

In regards to the ability to inline edit alt text without errors…you can already do this. When you click on the “Alt Text” menu at the top, it takes you to the table of all found “alt text” (with and without errors) on the site per the settings you have defined. If you are only seeing rows for alt text that has errors, then you have a specific filter applied. If you are accessing the table by clicking on the specific errors from the dashboard, then it is applying the “issue” filter for you automatically. You can remove that filter by changing it to “– issue –“. I am aware that the label is misleading. If I misunderstood your request, please let me know.

Preview “Alt Text” Truncated

As with anything that we build, users will use it in ways that we cannot foresee or we do not recommend. In this case, you are placing large amount of data into the “alt text” field, which we do not recommend, but we understand. When we decided to change the column type in the index table to allow longer values, we had to truncate the retrieval so we could prevent the user from running out of memory and causing a fatal error. When you inline edit the alt text, it does an ajax request, so we are able to pull the full length with no memory issues. In short, you are doing bulk processing with large amount of data which pushes the normal limits of memory. The new table column type in the database allows for very large string lengths. We have to truncate the value at some point to prevent running out of memory and so that the long alt text does not distort the view of the table.

• Memory Fatal Errors – A solution for this would certainly involve batch ajax/rest-api requests to generate the output of the table with full length alt text and all rows in one table. The question is, how hard would this be for me to implement and how long would it take? Let me think on this over the weekend and get back to you.
• Distorted Table – We could allow the view of the table to not max out at a specific pixel width allowing you to use a larger screen and accomodate very long alt text within the table. This was not considered before as we didn’t expect very long alt text values.

-Steven

oh, i wasn’t trying to display them in a non-paginated table, just in the table the way it is. the memory issues would kill me on a single table for sure. i didn’t realize you could already do exactly what i was looking for by clearing the filters. that’s absolutely perfect!

yes, many of the images being displayed in this site in particular are well into the thousands-of-characters range because of the nature of what they are. definitely not a perfect solution but that’s what an image-only social media world looks like when you’re publishing directly into platforms like instagram that don’t support text content. the site is realistically just a searchable and linkable archive of thousands of images, most full of text. not perfect for seo but having the text content in the alt tags means it works perfectly for accessibility and that’s really the target for me in this case – pretty much all the traffic is coming from social media links because it’s easier to browse on the site than through instagram/tiktok, etc. especially when the alt tags allow the content to be searchable, something that can’t be done on the social media platforms because they’re not really meant for text publication.

it probably wouldn’t be worth the effort to implement batch ajax requests to build the table. you can avoid all the coding headache and pass the workload to the browser by adding a link to a javascript command to open all the edit blocks at once.

jQuery(".edit-inline a").click();

i looked at the code and disabled the truncation in the sql query and it had no problem loading 100 records ranging between 300 and 5000 characters per alt text block for me with no memory or timeout issues but that certainly doesn’t mean it couldn’t be a problem for other people. for me, i can just change the few lines in the table and ajax files for my personal needs rather than you needing to worry about it and do lots of testing to make sure it’s safe for everyone.

@avisato,

I like your idea about using jQuery to reveal the textarea edit boxes. Unfortunately, if you were showing 100 rows in the table and triggered a click on all 100 rows of edit links, then (the way it works right now) would trigger 100 AJAX requests to hit your server simultaneously. I’m not sure if that would be problematic or not, as AJAX requests are pretty lean in resource usage, but it is a very inefficient way of doing it. It basically comes down to memory versus CPU and I have to make sure this plugin works for a small sites as well as large sites. IF I crash someone’s small site because I give them the tools to do so, then they will be mad at me :).

With your idea: I think it would be cool to have an “Edit All” link at the top right that you clicked to reveal all the textarea fields at once; then, you could go through and edit, then save as needed one by one. I’ll look into this as I could see this being a big time saver. Less clicks and less cursor movement involved, is less time, which is the whole point of this plugin (time saving). I just would have to solve the memory/CPU issue if it exists, or put protections in place to warn/prevent people from crashing their site themselves.

Bug Fix: I am investigating the escaping issue with the textarea fields. I’ll work on that today and get that fix released soon.

-Steven

as for jquery, i even expanded the result set to 500 and it worked fine on my server but i admit it is running on a pretty powerful machine with lots of memory so that’s not necessarily a guideline. doing it with jquery should be series rather than parallel requests to the server so not all at once but definitely one right after another. there is a setting for allowing parallel jquery requests but as far as i can tell it’s done sequentially in the wordpress installation by default. it’s definitely inefficient but doing it on the backend that doesn’t worry me too much. if thousands of users were doing something inefficient at once, that would be a big issue. me doing it from time to time i can handle. so far, batches of 100 haven’t slowed anything down at all and i’ve been watching server performance while doing it just out of curiosity.

might be a good thing to have it as like an advanced setting in the settings menu with a warning. some plugins have expert features where they say use at your own risk for things like “may overload server” or “may exceed memory requirements”. if it’s all in a single table, you could batch-grab the whole output of 25 or 100 results into the table as a single json request. even in a result set of 100 records with 1000 characters each, that’s still only 100kb so not a huge amount of overhead. if you’re grabbing the content into the table already, editing might not even need to to an ajax request to start, only to save. just a thought, though.

the issue with the escaping is about the difference between html escape characters and sql escape characters. they only need to be escaped if they’re problematic for sql (single quotes, double quotes) and you can avoid that problem completely by converting them to their html equivalents and back. then you never get a sql error on mismatched escapes. if you swap ” to " and ‘ to ' when storing to the table and the reverse when loading, pretty much everything else can just remain. there would be issues with other special characters like \ but those aren’t even functional for most alt-text purposes so they could probably be stripped just like linefeeds.