[feedback] Image upload directly in the write tab

Bloke · 2016-05-12 10:54:09

NicolasGraph wrote #299069:

The only thing that comes in my mind for now is that I often use multiple images id’s… upload several images or add one without removing the previous… remove link… a dedicate submission for files, independant of the article saving?

And this is precisely the main reason why we have so far shied away from implementing any form of image management to the Write panel: there are so many different people that want so many different things, we’d end up inconveniencing a lot of folk.

Some want multiple images. Some want previews. Some want to adjust. Some want a popup to select from the existing images. Some want drag ‘n drop. Some want reordering… the list goes on.

My view is (and always had been) that our eventual implementation should be very basic. Oleg’s mods above show how easy it can be to customise, which means plugins can spring up to handle many different scenarios that override or augment the default behaviour. Each should cater to one or more of the options in the previous paragraph.

etc · 2016-05-12 10:57:30

NicolasGraph wrote #299069:

The only thing that comes in my mind for now is that I often use multiple images id’s in the Article image field so I’d really like to be able to upload several images or add one without removing the previous. It would mean that we’d need a remove link under the preview or something like that but it is maybe not bad because we could also more explicitly display the Edit link…

Thanks for the feedback, nice ideas. The aim was to allow multi-part forms uploading, to enable the use of <input type="file" /> handlers. The plugin is only for illustration, but multiple files upload in add/replace mode should be doable, will try it. Or go ahead and do it yourself, it’s a plugin. ;)

I don’t know, maybe the easiest way would be to have a dedicate submission for files, independant of the article saving?

That was already possible, not the purpose here.

NicolasGraph · 2016-05-12 11:27:06

etc wrote #299072:

Thanks for the feedback, nice ideas. The aim was to allow multi-part forms uploading, to enable the use of <input type="file" /> handlers. The plugin is only for illustration, but multiple files upload in add/replace mode should be doable, will try it. Or go ahead and do it yourself, it’s a plugin. ;)

Ok, that was my first thoughts but I’ll need to look deeper to see exactly how it works. I understand the Stef point of view and I love the way Textpattern keeps things simple so if this experiment can be easily enhance with plugins that’s great! …And you’re right, I’ll probably try to work on a plugin if the formdata go into the core.

Last edited by NicolasGraph (2016-05-12 11:27:40)

etc · 2016-05-12 14:30:07

Plugin updated to enable multiple files upload in add/replace mode. I leave further enhancements with image aficionados.

NicolasGraph · 2016-05-12 15:47:46

etc wrote #299076:

Plugin updated to enable multiple files upload in add/replace mode.

Incredible Oleg… :D

Pat64 · 2016-05-13 09:05:19

Simply amazing Oleg ;)

etc · 2016-05-13 09:50:01

Merci les gars, that was amazing to do too. I will push it to the master soon, happy plugin writing!

Pat64 · 2016-05-26 15:59:11

Hi Oleg ;)

I don’t know if that is very difficult: maybe you could add the current article title as a default “alt text” to image. What about multiple images? Better it will be to have a same “alt text” for all different images than nothing at all.

etc · 2016-05-26 16:36:51

Pat64 wrote #299302:

maybe you could add the current article title as a default “alt text” to image. What about multiple images? Better it will be to have a same “alt text” for all different images than nothing at all.

Hi Patrick,

valid point, thanks. I have updated the code adding image name as alt (see $meta = array('alt' => $file['name']); line). Feel free to replace it with article title ('alt' => $rs['Title']) or whatever you want — I don’t know what is the most pertinent choice here.

jpdupont · 2016-05-27 07:29:05

Hi Oleg,

Don’t work with the last 4.6 dev.
Normal ?

Edit : I understand now : I must save the article to see the image !

Last edited by jpdupont (2016-05-27 07:40:22)

etc · 2016-05-27 10:25:38

Hi Jean-Pol

jpdupont wrote #299313:

I understand now : I must save the article to see the image !

Yes, as with other fields. It’s not difficult to add auto-saving or image preview with few lines of js, though. I have updated the code for preview illustration (needs a browser with FileReader support), but don’t make me write a fully-featured image upload plugin, diy. ;)

etc · 2016-05-27 10:47:40

Incidentally, it would be great to place the Save button at some fixed position, say in theme’s <header />. Scrolling to the top to save changes is unpractical with long articles.

phiw13 · 2016-05-28 01:19:14

etc wrote #299316:

Incidentally, it would be great to place the Save button at some fixed position, say in theme’s <header />. Scrolling to the top to save changes is unpractical with long articles.

For my own theme, I’ve been thinkering with setting the whole sidebar on the Write panel to position:sticky for larger displays (desktop browsers, larger iPad type devices).

jakob · 2016-05-28 08:46:58

etc wrote #299316:

Incidentally, it would be great to place the Save button at some fixed position, say in theme’s <header />. Scrolling to the top to save changes is unpractical with long articles.

I have to say, I like the predictability of having all the save buttons at the top but totally understand your thinking. In the thinner viewport widths, it’s currently not at the top of the page but at the top of the sidebar / bottom of the main column.

phiw13 wrote #299327:

For my own theme, I’ve been thinkering with setting the whole sidebar on the Write panel to position:sticky for larger displays (desktop browsers, larger iPad type devices).

Sounds good too. Can there be problems with lengthy sidebars that are longer than the viewport height, or am I muddling that with position:fixed?

Phil, is Oleg’s suggestion feasible at this late juncture? Even if it still scrolled in Hive for the meantime, it would be good to allow others to be able theme it stuck if they so wished.

phiw13 · 2016-05-28 09:32:13

jakob wrote #299332:

I have to say, I like the predictability of having all the save buttons at the top but totally understand your thinking. In the thinner viewport widths, it’s currently not at the top of the page but at the top of the sidebar / bottom of the main column.

which is quite good. It is easily accessible on not-so-wide displays. Making it position: fixed on those displays will only get it in the way (cover) editing fields.

Sounds good too. Can there be problems with lengthy sidebars that are longer than the viewport height, or am I muddling that with position:fixed?

Partly, with position: sticky you still can scroll the whole thing. My first test a couple of day ago worked reasonably well, but I had all sub panels in the sidebar collapsed. Once I tested on a real install, with a number of sub panels open, it didn’t work that well.

But this worked well – for me, with my theme:

@media (min-width: 1025px) {
	#article_form  .txp-layout-4col-cell-4alt {
		position: relative; /*position: -webkit-sticky; top: 10em;*/
	}

	#article_form .txp-save {
		position: -webkit-sticky; top: 0.7em; z-index: 100;
	}
}

The save button sticks over the header once one scroll down the page. I think something similar would work for Hive, modulo some adjustment to the top value. Add -moz- prefix for Firefox of course (or did they unprefix it already? I don’t think so). Chrome and Edge do no support it yet (it is in the work for Edge, afaik).

—-

Phil, is Oleg’s suggestion feasible at this late juncture? Even if it still scrolled in Hive for the meantime, it would be good to allow others to be able theme it stuck if they so wished.

one thing: PLEASE do not move the save button in the <header>, code wise. It would 1/ not be very semantic and 2/ pretty poor in terms of accessibility. Think keyboard users and screen readers alike.

Textpattern CMS support forum

#16 2016-05-12 10:54:09

Re: [feedback] Image upload directly in the write tab

NicolasGraph wrote #299069:

#17 2016-05-12 10:57:30

Re: [feedback] Image upload directly in the write tab

NicolasGraph wrote #299069:

#18 2016-05-12 11:27:06

Re: [feedback] Image upload directly in the write tab

etc wrote #299072:

#19 2016-05-12 14:30:07

Re: [feedback] Image upload directly in the write tab

#20 2016-05-12 15:47:46

Re: [feedback] Image upload directly in the write tab

etc wrote #299076:

#21 2016-05-13 09:05:19

Re: [feedback] Image upload directly in the write tab

#22 2016-05-13 09:50:01

Re: [feedback] Image upload directly in the write tab

#23 2016-05-26 15:59:11

Re: [feedback] Image upload directly in the write tab

#24 2016-05-26 16:36:51

Re: [feedback] Image upload directly in the write tab

Pat64 wrote #299302:

#25 2016-05-27 07:29:05

Re: [feedback] Image upload directly in the write tab

#26 2016-05-27 10:25:38

Re: [feedback] Image upload directly in the write tab

jpdupont wrote #299313:

#27 2016-05-27 10:47:40

Re: [feedback] Image upload directly in the write tab

#28 2016-05-28 01:19:14

Re: [feedback] Image upload directly in the write tab

etc wrote #299316:

#29 2016-05-28 08:46:58

Re: [feedback] Image upload directly in the write tab

etc wrote #299316:

phiw13 wrote #299327:

#30 2016-05-28 09:32:13

Re: [feedback] Image upload directly in the write tab

jakob wrote #299332:

Board footer