Inline attachment image will not accept height and width values

[Antechinus]

Ok, so if I insert an image as an inline attachment, I can enter a height and width in the inputs, and it will be inserted at that size. Fine, as far as it goes.

However, if I then decide I want to change the displayed size of the image, and I go back to the attachment preview, and enter new width and height values in the inputs, then save that, it does nothing.

Now yes, I know what you are going to say: use BBC mode and edit the values directly in the post. Sure, I can do that. but what about non-techy mugs who use WYSIWYG and are lost with anything else? WYSIWYG mode was included for people like that, and they will expect to use it.

But, let's say you're thinking "Well **** them. They can edit with BBC mode anyway." Fine, but in that case... why are non-functional inputs being displayed anyway?

Visually, they look exactly the same as when they did work. There's no indication that they will not work. If they aren't going to work after the image is inserted inline, why are they still displayed in the preview? Particularly given that saving wasted space on mobile is important these days.

Tangentially-related issue: why does the drag-and-drop box still display when you have used up the limit on the number of attachments? And why is the text telling you this not bold?

And why display two messages when surely one message would be perfectly adequate?

Restrictions: 0 attachments remaining
You have reached the maximum number of attachments allowed per post.

[Antechinus]

Speaking of messages...

Damn, those language files are inexplicably brittle. Some strings can use HTML tags and entities normally, like SMF language files have always been able to. Other strings (for example, $txt['attach_max_size_progress'] ) just spit their dummy and spew the raw HTML to the browser instead of actually rendering it.

Seriously: WTF is going on with that? Since when have we not been allowed to use basic HTML in language strings? And why only some of them, now, without any explanation?

[Arantor]

Because people wanted to use .text instead of .html in jQuery, and have the sizes as placeholders.

As per: https://github.com/SimpleMachines/SMF/blob/863ab1dec7f1aeb23b2e8faa48d18ff414a9c067/Themes/default/scripts/smf_fileUpload.js#L61

Honestly though the more I see debates on the attachments the more I want to just rip it out and replace the entire system, binding uploaded files to the editor first and foremost so you could have a WYSIWYG editor for editing general pages and add images to it without explicitly uploading them somewhere first. But that's a lot of new architecture.

[Antechinus]

I have no f***ing idea what language strings are doing in a jQuery javascript file. I'm not sure I want to know either.

Now I'm wondering how hard it would be to rip them out of there and just go back to using standard language strings (that have always worked, and are easy to edit).

[Arantor]

Simple, the language string has to be dynamically processed and updated as you add files - there's no server round trip queueing up the files and seeing quotas and stuff until you *actually hit upload*.

This *is* a standard language string, defined in Post.language.PHP and exported to the front end for use like almost any other. The one difference here is that the language string's processing doesn't allow HTML, but that's true for *surprisingly many* of the language strings anyway.

[davo88]

Honestly though the more I see debates on the attachments the more I want to just rip it out and replace the entire system...

Now you're talking. That's what needs to happen. Images are such a fundamental part of communication, it has to be really easy to mix them in with your text.

[Antechinus]

Simple, the language string has to be dynamically processed and updated as you add files - there's no server round trip queueing up the files and seeing quotas and stuff until you *actually hit upload*.

Yes, I realise it has to be processed on the fly, but offhand I see no reason why it couldn't be processed on the fly while still allowing HTML.

All it has to do is call one variable. It should not be imposing restrictions on the markup around that variable, any more than it should impose restrictions on the text around that variable. If it does, someone probably has not thought things through.

This *is* a standard language string, defined in Post.language.PHP and exported to the front end for use like almost any other. The one difference here is that the language string's processing doesn't allow HTML, but that's true for *surprisingly many* of the language strings anyway.

Ok, so *surprisingly many* strings break the standard language editor functionality (one of SMF admin's best features) without any warning, and this has never been mentioned or documented before. Sounds like a cock-up.

[Arantor]

If you'd read the comment I actually left and replaced the .text with .html in the piece of code I'd pointed to, it *would* support markup. Because that's all that happens - the language string is exported out as-is, it gets a last-minute find/replace on the {parameters} in {braces} and is inserted as a text node into the DOM.

But I can give you many, many more examples of language strings that behave weirdly. Why do you think the language files have 'use entities in the following strings' splattered everywhere? Answer: because using markup on them breaks them. Even using named entities like amp can break them.

[Antechinus]

If you'd read the comment I actually left and replaced the .text with .html in the piece of code I'd pointed to, it *would* support markup. Because that's all that happens - the language string is exported out as-is, it gets a last-minute find/replace on the {parameters} in {braces} and is inserted as a text node into the DOM.

I did read it, but I did not get the allusion (it was roughly 11 pm here and I was about to crash). But if it's that easy to fix then, frankly, it should be fixed.

But I can give you many, many more examples of language strings that behave weirdly. Why do you think the language files have 'use entities in the following strings' splattered everywhere? Answer: because using markup on them breaks them. Even using named entities like amp can break them.

Awesomesauce. No, I had never noticed this. I just assumed that all language strings behaved the same way, and were fully editable, because that's what I had been led to believe.

[Antechinus]

Side issue: the message is badly thought out anyway, regardless of markup. The choice of variables is problematic in itself.

No user is going to give a damn about the total number of bytes allowed, or the total bytes in files they have already attached. Any average user is only ever going to want to know one figure: how many bytes they have left before they hit the limit.

This is the only figure that it is actually useful to echo to the browser, and it is the only figure that is NOT currently echoed to the browser. This is, frankly, poor UX. It should have been obvious that making everyone do mental arithmetic every time they consider a new attachment was, putting it mildly, a sub-optimal solution.

ETA: Hang on an effing minute. Looking at that js...
 https://github.com/SimpleMachines/SMF/blob/863ab1dec7f1aeb23b2e8faa48d18ff414a9c067/Themes/default/scripts/smf_fileUpload.js#L61

Code Select Expand

$('#max_files_progress_text').text(myDropzone.options.text_max_size_progress.replace('{currentTotal}', maxSize).replace('{currentRemain}', currentSize));

My javascript isn't much chop, but does this mean that it is DELIBERATELY replacing the one figure that would be any use with the total number of bytes already uploaded? And doing this WITHOUT any indication that the variable name in the language file is now misleading?

ETA again: Lol. Yes, that is exactly what it is doing. .
Ooooooooooooo kkkkkkkkkk: javascript can be like this:

Code Select Expand

// Show or update the text.
$('#max_files_progress_text').html(myDropzone.options.text_max_size_progress.replace('{currentRemain}', maxSize - currentSize).replace('{maxSize}', maxSize));
Language string can be like this:

Code Select Expand

$txt['attach_max_size_progress'] = 'You have <strong>{currentRemain} kB remaining</strong> of the total size allowance ({maxSize} kB).';
Hey, presto! The GUI will now tell users exactly what they need to know. Easy.

Oh, and now the variable names in the language file actually match what they does in reality (which is not mission-critical, but is generally a damned good idea nonetheless).