New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import files #20

Closed
nilshoerrmann opened this Issue Oct 30, 2014 · 10 comments

Comments

Projects
None yet
2 participants
@nilshoerrmann
Member

nilshoerrmann commented Oct 30, 2014

It seems like this extension is having problems to import files using XML Importer, if an entry had manually attached files first: the old file will e removed from the database and the new one will not be attached. The file system is unaffected.

Entries with no files attached seem to work as well as entries that have been successfully imported before (no manually attached files).

Doesn't make a lot sense to me yet.

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Oct 30, 2014

Member

@brendo: Am I right, that providing this field with a /filena.me of an existing file in the destination folder should just work like this:

  • Same file was attached before – all good, nothing to do.
  • Different file as before – unattach old, attach new.
  • Additional file – leave old, attach new.
Member

nilshoerrmann commented Oct 30, 2014

@brendo: Am I right, that providing this field with a /filena.me of an existing file in the destination folder should just work like this:

  • Same file was attached before – all good, nothing to do.
  • Different file as before – unattach old, attach new.
  • Additional file – leave old, attach new.
@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Oct 30, 2014

Member

There seems to be a more fundamental issue:

If I look at the following lines, https://github.com/symphonists/multiuploadfield/blob/master/fields/field.multiupload.php#L190, I'd expect all imported files to have file meta data. This is not true on our install: all imported entries (those that are workin) in the database have only the entry id and the filename stored.

Member

nilshoerrmann commented Oct 30, 2014

There seems to be a more fundamental issue:

If I look at the following lines, https://github.com/symphonists/multiuploadfield/blob/master/fields/field.multiupload.php#L190, I'd expect all imported files to have file meta data. This is not true on our install: all imported entries (those that are workin) in the database have only the entry id and the filename stored.

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Oct 30, 2014

Member

This is getting stranger: For a file that doesn't get imported, I've added the entry to the database manually by just storing the filename. The backend now shows a file entry but highlights the file as missing or unreadable, but I can confirm that the file exists (correct destination and name) and is readable (777).

Are there any naming conventions a file has to confirm to?
Is it possible that newer PHP versions changed the behavior of this extension (there was an server update recently).

Member

nilshoerrmann commented Oct 30, 2014

This is getting stranger: For a file that doesn't get imported, I've added the entry to the database manually by just storing the filename. The backend now shows a file entry but highlights the file as missing or unreadable, but I can confirm that the file exists (correct destination and name) and is readable (777).

Are there any naming conventions a file has to confirm to?
Is it possible that newer PHP versions changed the behavior of this extension (there was an server update recently).

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 30, 2014

Member

Try the integration branch, think this is fixed up now :)

Member

brendo commented Oct 30, 2014

Try the integration branch, think this is fixed up now :)

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Oct 30, 2014

Member

Cool, I'll check tomorrow!

Member

nilshoerrmann commented Oct 30, 2014

Cool, I'll check tomorrow!

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Oct 31, 2014

Member

I will push this to a site early next week that imports images regularly and will report back, if it works.
Looking good so far.

Member

nilshoerrmann commented Oct 31, 2014

I will push this to a site early next week that imports images regularly and will report back, if it works.
Looking good so far.

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Oct 31, 2014

Member

Okay, I was able to test the change today with an import of aroudn 2000 entries and the problem still exists. I'll further debug this next week – the strange thing is that some files work and some don't so I'm not sure if the source of the problem lies somewhere else.

Member

nilshoerrmann commented Oct 31, 2014

Okay, I was able to test the change today with an import of aroudn 2000 entries and the problem still exists. I'll further debug this next week – the strange thing is that some files work and some don't so I'm not sure if the source of the problem lies somewhere else.

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Nov 4, 2014

Member

I just had a deeper look at this, and the commit above fixes all general issues around importing of entries that already exist in an install. All other problems we had were related to typos in the import file.

Thanks again Brandan for the update!

Member

nilshoerrmann commented Nov 4, 2014

I just had a deeper look at this, and the commit above fixes all general issues around importing of entries that already exist in an install. All other problems we had were related to typos in the import file.

Thanks again Brandan for the update!

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Nov 4, 2014

Member

No worries, glad it's resolved. I'm guessing this means a new master release can happen now?

Member

brendo commented Nov 4, 2014

No worries, glad it's resolved. I'm guessing this means a new master release can happen now?

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Nov 4, 2014

Member

I haven't checked direct uploads yet (something @johannahoerrmann could do on the project she was working on, see #18). If that works as well, a new release is good to go :)

Member

nilshoerrmann commented Nov 4, 2014

I haven't checked direct uploads yet (something @johannahoerrmann could do on the project she was working on, see #18). If that works as well, a new release is good to go :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment