XF 1.4 Importing from SMF 2.x - Attachment problems

[Cmely]

I'm trying to import database from my previous SMF 2.x forum.

I'm using XF 1.4.3.

On my SMF forum, avatars and attachements are stored in the same folder. So I left blank the second field when was asked for avatars and attachements folders.

First time I ran the importer, I had no errors but no results : members didn't had their avatars and no pictures were attached to posts.

So, I've downloaded the improved Importer in this thread : https://xenforo.com/community/threads/smf-importer-beta-improvements.87526/

Now there is some progress :

- Avatars are correctly found

but
- I've some errors when it comes to importing the attachements :

First error is :
Fatal error: Out of memory (allocated 84148224) (tried to allocate 2448 bytes) in /homepages/32/d343239575/htdocs/Luxoptima_XF/library/XenForo/Image/Gd.php on line 215

And then when I get back to the import panel I've got those errors :



Do you have any suggestions ?

 

[Cmely]

Just a precision : when checking the attachment browser, aproximatively half of the attachments have been correctly imported. I suppose import stop because of the error.

 

[Chris D]

Indeed. You will need to address the first error first because resizing images is quite intensive (at this stage we're copying all of the images and creating new thumbnails for them). The solution would usually be to raise the max_memory_limit in PHP. XenForo usually tries to override this at run time to 128M but you may want to consider that as a minimum and go higher if you can.

After that, you will need to delete the most recent attachments. You should be able to delete these from the Attachment Browser in the Admin CP. It's currently trying to re-import the attachment with the ID 238 and it already exists (hence the duplicate error).

In the attachment browser, if you hover over the attachments in the list you'll see a URL like:

http://yoursite/admin.php?attachments/file-jpg.238/view

That would be the one you delete, though depending on how far it got through the process you may need to do this multiple times before it can continue.

Another solution would be to start the import again, but depending how large the import is, that may not be trivial.

 

[Cmely]

Indeed. You will need to address the first error first because resizing images is quite intensive (at this stage we're copying all of the images and creating new thumbnails for them). The solution would usually be to raise the max_memory_limit in PHP. XenForo usually tries to override this at run time to 128M but you may want to consider that as a minimum and go higher if you can.

Thank you Chris.
I'm afraid I didn't understood completely this part . Could give me a little bit more details about how to raise the max memory ?

 

[Chris D]

It's a server configuration. You would likely need to contact your host if you are unsure or unable to do it yourself.

 

[Mike]

There may be another option which can help by adding a line to config.php: https://xenforo.com/help/config-php-options/

Specifically, add a line like:

$config['maxImageResizePixelCount'] = 10000000;

This will reduce the maximum dimension of an image that will be resizable, but the dimensions directly relate to the amount of memory PHP needs to manipulate an image. Adding that restriction should help prevent the error.

 

[Cmely]

Thank's Mike and Chris fortrying to help me.
I've tried Mike's idea, but it makes no differences.

The picture 238 is a 440*83 px and 6.5 Ko picture. It shouldn't have a big impact when resizing ?
If I try to delete it and continue importing, I don't have anymore the "out of memory" first error but I end up directly on the second error.

Is there any way I can bypass some pictures import ?

 

[Chris D]

Obviously in my previous post I did advise on how to get past the duplicate key error. That advice still stands.

The only way to bypass some pictures is to delete them from the source database (though it is advisable to back those up, first, of course).

 

[Cmely]

Obviously in my previous post I did advise on how to get past the duplicate key error. That advice still stands.

I know and I'm currently investigating this one...but as I'm not very comfortable with it, this is why I've tried Mike's suggestion first...just in case it would help me to avoid the difficulty...

Is it in "php.ini" file that I do change this value?
On my server "memory_limit" is currently set to 81M. What value would you suggest?

 

[Chris D]

That wasn't actually what I was referring to. I was referring to my advice with regards to bypassing the duplicate key errors, e.g. deleting the existing data from the Attachment Browser.

But, yes, that first point with regards to changing the memory_limit is in php.ini. XenForo tries to set at least 128M, but what's appropriate would very much depend on your server.

 

[Cmely]

That wasn't actually what I was referring to. I was referring to my advice with regards to bypassing the duplicate key errors, e.g. deleting the existing data from the Attachment Browser.

Oh, sorry.
I've tried that but it's running in circle : if I delete picture 238 then it stop on picture 239...if I delete picture 239 it goes back and stop again on 238.

If I delete 238 and 239 it stop on picture 240 ... if I delete 238 and 239 and 240 .... then picture 241 (or whatsoever)...should I continue this way : by deleting n pictures, then n+1, then n+2 pictures or am I supposed to delete only one picture at a time ?

 

[Mike]

You need to find the value it stops on and then delete anything with an ID higher than that.

 

[Cmely]

Yessss !



Thank you very much for your help, it worked fine!

You can mark this thread as solved if you wish.

I have however a small additional question : what would be the easiest / quickest / smartest way to switch all attached pictures to "Full Image" (in post) instead of having them as thumbnail?

 

[Paul B]

Assuming the images are embedded using the basic attach tag, you can run a query to replace attach with attach=full.

UPDATE xf_post SET message = REPLACE(message,'current_content','new_content');

Take a backup first.

 

[Cmely]

Thank you very much Brogan.