[Kobus]

Hi guys,

 

I am currently pushing GC to its limits, I think :-) Hoping someone has some advice for me about the below...

 

Before I go on, I want to state that I did try Image Crud for this purpose, but it came up short for my needs as well. GC is much more mature, so I figure it will be easier to do in GC than in IC.

 

I am trying to create image galleries in Facebook style in functionality: first you create a gallery with some meta data, and afterwards you upload images into the gallery. Up to this point I got everything working - GC is powerful like that. :-)

 

Now comes the problem. I need to intercept the file upload process for the image, because:

 

1. I need to first process the image uploaded in various ways using CI's image library (max width, max height, etc.).

2. Generate a thumbnail of the uploaded image and save it to a different folder. I need to crop the image to give the thumbnail a fixed with and height across the bank.

 

IN MY CURRENT REASONING, I am leaning towards using callback_after_insert and callback_after_update to process this AFTER saving the item to the database, and it would most likely be the easiest way to do so, unless someone has a better suggestion for me.

 

As you can see from the above problem description, GC out of the box will not work to "intercept" the upload process, but can work using my above suggested plan. Is this the best way to do this? Any other suggestions?

 

Thanks in advance for your replies :-)

 

Kobus

[briggers]

Hi,

 

You intercept the upload using callback_after_upload

 

See my reply in thread saving-image

 

The controller does almost what you want to do.

[Kobus]

Brilliant, thank you, briggers. I didn't realize there was a callback for that.

 

*/me jumps and starts coding* :-)

[davidoster]

Some sample code I did that combines the two GC - IC together a while back...

might give you some more insights!

 

/topic/1326-how-to-use-grocery-crud-and-image-crud-together/page-2#entry5737

 

 

Good luck [member=kobus] and if you wish/can please share your final code.

 

P.S. I found a bug of the forum by the way.

[member=web-johnny], when you want to get the permalinkof a comment that is not on the first page it comes like this e.g.

/topic/1326-how-to-use-grocery-crud-and-image-crud-together#entry5737

where it should be like the above!

Interesting!

[Kobus]

Hi David,

 

I ended up using briggers' solution, without Image Crud. It works pretty decently, in my opinion. The only problem with this is that I can upload only one image at a time. Maybe for a future version, I will upgrade to your solution, but not now - the client is breathing down my neck for their "super duper image gallery" :-) Hehe.

 

Regards,

 

Kobus

[Kobus]

Very nice post, briggers. I have implemented it successfully except for one thing, which I am still looking for a proper solution: My image uploads fine, but once uploaded, it displays the large uploaded file. I want to change it to the newly created thumbnail instead. I tried callback_column, callback_edit_field and callback_add_field, and that works on to a degree. The problem is that it replaces the entire delete and lightbox functionality of the views. Any idea how to resolve this problem?

 

Then there is a minor problem (but not with your script, I believe) and that is that the newly created images only delete images on deletion of the post. If I were to continually delete the image in edit/add mode, every thumbnail will get created, but only the last one added will be deleted if I delete the post, resulting in orphan files. I tried looking for a callback similar to "callback_after_upload_delete" or something to that effect, but could not find anything such as that. Any ideas about this? Is there a callback I can use to delete the file upon deleting the file uploaded in the add/edit view?

 

Regards,

 

Kobus

[briggers]

Hi Kobus,

 

 

My image uploads fine, but once uploaded, it displays the large uploaded file. I want to change it to the newly created thumbnail instead. I tried callback_column, callback_edit_field and callback_add_field, and that works on to a degree. The problem is that it replaces the entire delete and lightbox functionality of the views. Any idea how to resolve this problem?

 

Not sure what is happening for you here. I am using Flexigrid theme and that gives the picture in the grid the class "image-thumbnail" and a height="50px" 

which when clicked on shows a lightbox larger version of the image.

This is the resultant html

<div class="text-left"><a href="http://.../assets/uploads/images/galleries/full/3d771-img_122.jpeg" class="image-thumbnail"><img src="http://.../assets/uploads/images/galleries/full/3d771-img_122.jpeg" height="50px"></a></div>

and the lines in my controller which makes all that happen are

.
.
.
$crud->columns('gallery_id','picture_title','picture_id','picture_file','picture_status','picture_owner','picture_create_date','picture_creator');
.
.
.
$crud->set_field_upload('picture_file','assets/uploads/images/galleries/full');
.
.

Maybe the datagrid theme works differently - which are you using?

 

I don't allow deleting or changing the picture itself in the "edit" form, just its description, name, etc. To me it only seems to make sense to delete the image from the database as well as the filesystem if you want to delete or change the image - otherwise you could have a picture named bus (in the database) but with an image of a car. So my edit form has only the following fields

$crud->edit_fields('picture_slug','picture_title','picture_description','picture_owner','gallery_id','picture_status','picture_create_date','picture_creator');

In add, the image is uploaded, stored in the filesystem shown as a thumbnail in the add form and has a delete link which works to delete the image from the filesystem and re-show the upload button - so if I mistakenly select the wrong image I can change it (delete - new upload) before saving the record. That works correctly as far as I can see. This has

$crud->add_fields('picture_slug','picture_title','picture_description','picture_owner','gallery_id','picture_status','picture_file','picture_create_date','picture_creator');

[Kobus]

Hi Briggers,

 

I am using Flexigrid as well - mine does not have the height attribute of 50px in it though. I am using GC 1.4. I will play around more though, perhaps add that height in my Flexigrid view file directly. I know it is sloppy, but will work :-)

 

I think you misunderstood my point about the orphan files. I think this will be best described by a step-by-step reproduction of this:

 

1. Create an image as per your script. Let's call the image "bus"

2. View the image in full, view and thumbnail, see that it is there in all three folders, with the same name.

3. Now edit the entry, and click on the delete link in the file upload field in the edit screen. The image "bus" is now deleted.

4. Now look in your file system folders. The old thumb and viewing images remains, although the full image has been deleted. These remaining thumb and viewing images are the orphan images I am talking about. If you upload a new file now in edit mode, you will now add a new image called "car", however, the thumb and viewing of "bus" still remain.

 

As I said before, this is not because your script - but because there is not a callback in GC for something like "callback_after_file_delete" or something like that :-)

 

Regards,

 

Kobus

[briggers]

Hi Kobus,

 

I don't really agree with allowing a user to change a file once it has been committed to the database but if that's what you want then I can see 3 ways to deal with or avoiding orphaned files.

 

1. Modify the core CG controller(/application/libraries/grocery)CRUD.php) to add if(file_exists(filepath)){unlink(filepath);} and repeat this for every possible filepath in your system.

I think that's in 5330 public function delete() - but check

 

This should not affect any other areas because of the condition. But I don't recommend this method because of the update to GC issue. You would have to move the code into any updated CG controller

 

2. Create a simple php command-line task which you can run from a cron job every day/week/month to delete any orphaned files - messy because it means checking every file in your upload folders against the database

 

3. Add an invisible or hidden callback_column holding the "old" image name from the database then use a callback_after_upload to compare the "old"name with the "new" name and if they differ to use a conditional unlink() (like in point 1) to delete all the "old" files. I don't have time at the moment to create some sample code for this, but it should be quite easy.

 

I'd opt for method 3 if I had to do it

 

Hope that helps

Richard 

[Kobus]

Hi Richard,

 

It is not that important to do - it was just an observation. I am not mquite sure what you mean by "changing a file". If I physically delete the file in the view to upload a new file in its place, it is an intended operation, and should be done, no? But it does not matter - I was just curious about that, and I spent some time trying to figure it out. I "hacked" GC core file to add a new experimental event (callback_after_upload_delete) but that did not work due to the callback not having access to the primary key of the post in which the file is uploaded. It is therefore not doable in GC's current way of doing things, so I removed my additions to be back at a vanilla GC core again.

 

Regarding the large image display, I found that this is because I use the callback to resize the image to create the thumbnail. If I do not call the callback, the right size image is displayed. Not sure how to fix it yet, but am looking into it.

 

Thanks for all your help.

 

Regards,

 

Kobus

[Kobus]

... I "hacked" GC core file to add a new experimental event (callback_after_upload_delete) but that did not work due to the callback not having access to the primary key of the post in which the file is uploaded. It is therefore not doable in GC's current way of doing things, so I removed my additions to be back at a vanilla GC core again....

 

 

I actually found a way to do this, and it works well. Since briggers' solution actually keep the filenames the same, just in different folders, I could use that to write my callback function, and inside the GC core, create a new callback "callback_after_upload_delete". The reason I could not use it before is because I tried to retrieve the filename from the database, and without the primary key, I can not retireve the row. But with the names being the same, and knowing what the folder names are, it is actually easy to do.

 

So - what this does is:

 

1. When in an edit screen, I delete an image, it calls the callback "callback_after_upload_delete",

2. The callback has access to the file's name, so I just iterate the directories again (same as callback_before_delete callback does in briggers' code).

 

Does anyone think that this will be a good addition to GC? If so, I will submit my callback via GitHub.

 

Regards,

 

Kobus

[Donna111]

Hi there

That exactly what i want to do.I was trying to create image gallery using a code.And i have googled this code:

namespace RE__Test
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
int width = 100;
int height = 60;

REImage reImage = new REImage(width, height, ImageMode.RGB888);// Create an image with specified width, height and color mode; all pixels are set to white

REFile.SaveImageFile(reImage, "c:/reimage.bmp", new BMPEncoder());
REFile.SaveImageFile(reImage, "c:/reimage.png", new PNGEncoder());
REFile.SaveImageFile(reImage, "c:/reimage.jpg", new JPGEncoder());
REFile.SaveImageFile(reImage, "c:/reimage.tif", new TIFEncoder());
}

 

But it can not work.What's wrong with my code?Is there any other code which supports to do that?Thanks for any suggestions.