Idea for field

[andrewminton]

Hi @nitriques,

I've created this repo as a proof of concept for overriding the destination folder on upload fields..

Use case is to be able to select a child/sub folder of the default destination folder given to you when you create an upload field in a section.

What I want is the ability to choose a sub folder of this destination folder when I edit an entry in order to keep my uploaded files as neat an tidy as the Database.

At present. when you upload files which you would want to categorize in the Database, you get one folder to upload them all, but I prefer to have the option to choose a child folder for a series of images instead of a huge folder with tones of images for a gallery.

We'l see how it goes, but I've made a start as an experiment.

I'm extending the Field and not the Upload Field, as I need to alter the DB tables for the experiment.... so going to work in isolation and see what works and doesn't.

If it becomes useful, it may be something to propose as an option/preference on the default upload field in the future.

[nitriques]

Great idea ! But I would really recommend to base your work on the image upload field, or at least the upload field.

The thing is, 99% of what you need is already in the the base field class. You say that you need to alter the DB table: that's fine. This is exactly what @vlad-ghita did. He inherited from the uploadField class, than overwrite the method he needed.

I your case, you could overwrite the createTable method to create your own. Remember that your field will never be related to the base one. It will have it's own name. You will be able to reuse behaviour. Remember to use the same column names than the one used in the base class.

You'll have to save the same values than those from the original upload field. You just have to do your magic in the path column.

Do not hesitate to ask me more questions. It is a pleasure to help you.

[andrewminton]

Thanks Nicholas!

I'm using this as learning experience so going back to the UploadField for lots of reference is proofing very educational.

Lots of fun!

The one thing with the UploadField is that there seems to be a lot of checks for the get('destination') in the field table... so I need a fair bit of conditional checks for my override check box to allow it to listen to my desired upload folder and populate the path entry field as well..

Fingers crossed this'll be useful.

Thanks for advice :)

[nitriques]

Yes! And if not, learning things is never lost time.

The one thing with the UploadField is that there seems to be a lot of checks for the get('destination')

Since this is only an keyed-array, it will be easy for you to change this.

As for the UI, it will be easy for you to reuse completely the upload's UI. You'll just have to insert an XMLElement of your own into the main div.

Commit and push often. I will refer to your code for the next advices!

[andrewminton]

Thanks again.

I've also noticed in the XMLElement for displayPublishPanel function, if I add the folder select options (which is already done) the JS removes all the markup when you click 'remove file' I guess the JS will need to be overriden as well you think?

[nitriques]

You could. Or you could 'wrap' the XMLElement from the parent into one of your own. Then, the .empty() call will clear only the right thing.

I just realize that this is the opposite of what I told you before. Sorry! I should I have though about this! My bad...

[nitriques]

Wow you have LOT of code already done!

There is really a problem of code reuse with fields in Symphony. It really should be refactored in order to facilitates could reuse.

Is it already working ?

[andrewminton]

Check the uploadfield branch.. Removed a lot.

So far, select box in entry field is rendering.. I just havent been able to overide the path with the upload select yet.

[nitriques]

Does the upload still works ?

[designermonkey]

@andrewminton I forgot to mention one of the benefits of extending a core field is that if this was to ever be pulled in, it has a definite upgrade path when it comes to merges.

If you started with that, then branch yours from it, any changes in the core field to methods that you have chenged can be easily seen an merged.

[nitriques]

Your uploadfield branch is way better IMHO :+1:

[nitriques]

@designermonkey You are right. But the thing is to avoid changing the core... But still benefits from changed/upgrades made in there.

Since I have your attention here, would you please check this discussion ? It has to do with your relationship problem. BTW, I am really thrilled that this topic is up for discussion. I would really like to help you on this. What can I do ?

[andrewminton]

@designermonkey Not sure I follow 100%. I'm extending the uploadfield now. Is that the right way to approach it?

@nitriques and @designermonkey Could you help me figure out the best way to grab the select directory in the new drop down I have inserted into the section entry upload field?

i.e How do I grab the $_POST data for the select option to use in the processRawFieldData function?

see this line for where I want to grab it: https://github.com/andrewminton/enhanced_upload_field/blob/uploadfield/fields/field.enhanced_upload.php#L208

[nitriques]

If you named your input/select/texarea correctly, it should be in the $data parameter variable.

I.e.

$XMLInput->setAttribute('name', 'fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix);

[nitriques]

This is is event better, since it is a select

$XMLSelect = Widget::Select('fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix)', $values, array());

[andrewminton]

Does that mean that the select option I choose will be added to the $data['image'] array then?

[andrewminton]

@nitriques, @designermonkey guys, what gets triggered first?

processRawFieldData or checkPostFieldData ? I can't seem to capture the select box post value in any array.

I'm trying to figure out how to add :

        $choosefolder = Widget::Select('fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix, $options);
        $choosefolder->setAttribute('class','enhanced_upload file');
        $span->appendChild($choosefolder);

Select box option chosen to the $data array but I think I'm missing the declaration to include it in the $data array somewhere..

[nitriques]

Does that mean that the select option I choose will be added to the $data['image'] array then?

If you set the correct name attribute, yes!

what gets triggered first? processRawFieldData or checkPostFieldData

checkPostFieldData will be fired first. Technically this is where you would want to do the most of the validation.

Check the comment I wrote to reminde myself :) https://github.com/Solutions-Nitriques/oembed_field/blob/master/fields/field.oembed.php#L101

BTW, you could compact the first two lines like this

$choosefolder = Widget::Select('fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix, $options, array('class'=>'enhanced_upload file'));

But I think you are missing somthing. The name of the select MUST be different than the one used for the upload input. So I would name your select like this

'fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix.'[select-box]'

[andrewminton]

Hi @nitriques, your last comment above is what I've just discovered... I've added [directory] to the end of the fields[image] so that I can get the [directory] element from post.

I've got it working in latest commit in my uploadfield branch!

Lot of cleanup to do as well.. but proof of concept seems to work eh!

[andrewminton]

Also, your previous comment about adding my own markup to this select box makes sense... I wasn't seeing the post data of my field when viewing a var_dump of the $data.. It was because the js removed the selectbox when a new file is uploaded, So no post data was every collected.

After moving the XMLElement above the $span, I have the selectbox always visible for now. This way the $_POST data is visible to ensure it's being collected.

Next challange is hiding the select box when a file exists. There is no need for a folder select until we upload a new file!

[nitriques]

Lot of cleanup to do as well.. but proof of concept seems to work eh!

Congrats !

After moving the XMLElement above the $span, I have the selectbox always visible for now. This way the $_POST data is visible to ensure it's being collected.

Great !

[andrewminton]

@nitriques, @designermonkey,

So I've got it working on development and master branch now... merge todays commits.

That includes the hiding of the upload field when there is a file present in the upload field.

Woop.

If you spot anything that doesn't seem right, please feel free to raise an issue, and we'll look at it.

[nitriques]

:+1: :+1:

[andrewminton]

Might have issues with more than one upload field at the moment.. but we'll get that sorted soon enough.

[andrewminton]

When I say, I might have issues with more than upload field.. what I meant was, you might have had issues before, but I got bored and added that ability back in :)

Could anyone point me towards the best way to target the span.enhanced_upload select.enhanced_upload_hidden element using JS when I click the relevant for removing the file from the DOM:

$('em').click(function(){

    //$(this).parent().parent().children().addClass("clicked");

        $('.enhanced_upload select.enhanced_upload_select_hidden').addClass('show');

    });

This code changes all instances not the one I've clicked on.. not 100% sure how to target the one.. index maybe?

[andrewminton]

Ah bugger.. The core admin.js removes the 'em' from the DOM before my script gets a chance to affect the element.. So looking for a parent span of a dom element thats already been removed returns a null.. Cos it doesnt exist.

Is there a safe method to override the js for upload field in my extension? As in prevent the admin.js code from effecting my instance?..

Ah.. I think i've just figured it out... Define my own class for it and provide all the js myself... Right?

[designermonkey]

Yep ;)

andrewminton wrote:

Ah bugger.. The core admin.js removes the 'em' from the DOM before my script gets a chance to affect the element.. So looking for a parent span of a dom element thats already been removed returns a null.. Cos it doesnt exist.

Is there a safe method to override the js for upload field in my extension? As in prevent the admin.js code from effecting my instance?..

Ah.. I think i've just figured it out... Define my own class for it and provide all the js myself... Right?

— Reply to this email directly or view it on GitHub https://github.com/andrewminton/enhanced_upload_field/issues/1#issuecomment-10306777.

[nitriques]

I am pretty sure there is a way of doing it without coding your own js for the remove button... You can Always wrap thing around...

I will try to take the time to check this out tomorrow morning. (I am EST BTW)

[andrewminton]

@nitriques If you check my uploadfield branch, the field.enhancedupload.php file is now looking for child folders of the chosen destination folder in the Section Editor...

Which I think is a nice approach.. We are limiting folder choice to folders below the assigned one.. Just the JS/presentation markup to tackle now.

[nitriques]

looking for child folders of the chosen destination folder in the Section Editor

I thought that this was the MAIN purpose :P

It seems to me that your are missing a great this in calling the parent::methods.

Your code looks AT LOT like the upload_field code. Copy/pasting code is NEVER good.

Same thing would be true for css and javascript... You extension does not even require js...

[andrewminton]

Thanks @nitriques

I wasn't sure how much I could use the parent::methods with what functions... as in, if only a small part of the function needed to be changed, how to call the parent::method but override and add just a small part.

Lot's to learn indeed.

Yes,, the old child folder was the purpose of the extensions, I just needed to have all the other bits working and forgot to add it back in :)

'You extension does not even require js...'

What about revealing the selectbox when I click a single remove file button? That is dynamic client size change no?

On 13 November 2012 17:51, Nicolas Brassard notifications@github.comwrote:

looking for child folders of the chosen destination folder in the Section Editor

I thought that this was the MAIN purpose :P

It seems to me that your are missing a great this in calling the parent::methods.

Your code looks AT LOT like the upload_field code. Copy/pasting code is NEVER good.

Same thing would be true for css and javascript... You extension does not even require js...

— Reply to this email directly or view it on GitHubhttps://github.com/andrewminton/enhanced_upload_field/issues/1#issuecomment-10335575.

[nitriques]

if only a small part of the function needed to be changed, how to call the parent::method but override and add just a small part.

That's the challenge. You must try to "hack" this a bit. Symphony makes a lot of uses of keyed arrays. This is a good way of facilitating the hacking!

[andrewminton]

Hi @nitriques, spoke to soon on it working.

When I create a new entry, it throws an error stating the files cannot be uploaded.. it looks like the file $data array is missing when the entry is submitted.

Existing entries seem fine to edit and upload alternative files, but new files can't find the actual file I'm trying to upload.

If you had time, would you be able to point me towards the part I should be checking to resolve this issue?

[nitriques]

@andrewminton Sorry, I really do not have the time today. Will try to check it out tomorrow. Is the uploadfield branch the one I should check ?

[andrewminton]

Yes uploadfield branch.. No rush mate.

[andrewminton]

Hi @nitriques, I think I figured it out but not 100%

I was using fields[section_field][directory] as the input name on the selectbox for folders..

I got a feeling this was interfering with the image array..

By adding [enhanced_upload_field][section_field_name][directory] to the naming of each select box name, I have created my own array of $_POST data rather than messing with Symphony fields data array.

Fingers crossed this has now resolved issues when creating new entries.

Will keep testing anyways.

[nitriques]

Hi @andrewminton Just wanna let you know that I did not forget about you. Still haven't had the chance to check it though. Might have some in the week-end. Sorry for that but I have been really busy this week.

[andrewminton]

Hey its all good. This is open source coding man... When we have time, we play. My uploadfield branch has many changes and I'm still at a loss as to what code I can lose to benefit from extending the uploadfield class... This is where I could do with help really... The biggest change in latest round of commits from yesterday is integration of my own style class to accomodate new JS functionality... But i've just noticed a bug which has been introduced by doing this.... The selectbox triggers an explorer window to select a file for upload when you click it.. Not intended.. So will need to look into it..

Am around all weekend as Im working on a gocardless extension for pgi loader ;)

[nitriques]

This is open source coding man... When we have time, we play

Yes but I like to keep my promises!

extending the uploadfield class... This is where I could do with help really

This is what I really want to explore too!

[nitriques]

@andrewminton Still haven't forget about you yet!!! As you can see, I forked your repro and will play with it tomorrow. This week's is Open Source Maintenance week at work so I MUST do it! :P

[andrewminton]

:) heheh.. Cool.. Happy coding.. This week is invoicing week :(

[nitriques]

Are you done with invoicing ? (I am glad our co-ordinator does this for me!) I have installed your field... will play with it tomorrow!

[andrewminton]

Yup!

I am in and out of the studio today as I've been given the wonderful task of designing a set for a TV awards ceremony :) am on email and picking up notifications from Octodroid on my phone :)

On 23 November 2012 01:16, Nicolas Brassard notifications@github.comwrote:

Are you done with invoicing ? (I am glad our co-ordinator does this for me!) I have installed your field... will play with it tomorrow!

— Reply to this email directly or view it on GitHubhttps://github.com/andrewminton/enhanced_upload_field/issues/1#issuecomment-10648089.

[nitriques]

Hey @andrewminton !

I've (finally) manage to pull some commits into my fork! Looks promising. Feel free to browse the code.

I'll send you a pull request when I am done

[andrewminton]

Shweeeet!

I'm deep in code myself.. it's a WP plugin though.. I hate payment Gateways! just so much validation to deal with :(

Browsing the code now... thanks for taking a look by the way.. it was a small Idea I found useful.

cheers

On 28 November 2012 22:17, Nicolas Brassard notifications@github.comwrote:

Hey @andrewminton https://github.com/andrewminton !

I've (finally) manage to pull some commits into my fork! Looks promising. Feel free to browse the code.

I'll send you a pull request when I am done

— Reply to this email directly or view it on GitHubhttps://github.com/andrewminton/enhanced_upload_field/issues/1#issuecomment-10825462.

[nitriques]

WP AND Payments gateways sucks :P hahaha

I am not done yet, since it is not 100% complete, but as you can see, I removed a lot of code from the original source.

[nitriques]

Hi @andrewminton,

do you continue development of this project ? I forgot to send you a pull request, might do it Tuesday...

[andrewminton]

Yes, send pull request! I much prefer the cleaner less code you made on your fork :)

[nitriques]

Well it still does not work 100%... would you still want a PR or wait until I make it work at 100% ?

[andrewminton]

Let's wait if you have time or send pull to a new branch.. I'll call it nitriques :)

[nitriques]

great !