Backing off on using file entities to solve my file permissions issue

After a couple of days of struggling to populate the fields provided by file entity as part of my migrate module migration, I have thrown in the towel. I opened an issue with a feature request for migration support with the new version of the file entity module, but in the unlikely event that my request gets any traction I will probably have moved way past the point that I can still use it.

Here is a quick review of the things I tried:

  1. First I installed media module version 7.2.x and set up the field I wanted on the field. I also messed around with trying to get some kind of pdf thumbnail working.
  2. Moving on to trying to adjust my migration module I found migration support for file entity only for the 7.x.1 version of file entity in which the file entity module was part of the media module. I thought I had seen a file in the module when I was checking it out, but I currently see no evidence, so I must have been looking at something else.
  3. Realising that Migrate Extras provides unsupported support for an older version of media (I assume 7.x.1, but have not been able to attain any evidence). I attempted to downgrade media:
    1. I disabled and deleted the media 7.2.x version of the media module, and probably forgot to delete the file entity module.
    2. I downloaded and attempted to install the 7.1.x branch of the media module, and got some severe database errors about tables not existing
    3. After a lot of research, reading, and attempts at installing, uninstalling, and reinstalling different combinations of the modules in question, I found a thread where someone pointed out how to run a drush script to manually trigger an update script that will cause the necessary tables to be created. It seems that the system was stuck thinking it had a newer version of the schema than what I was installing, causing it to ignore the necessary changes to the database.
  4. Finally having, what I assume is the right version of media installed, and the field I need recreated, I proceed to try all manner of changes to the docfile migration that I currently use to import the files into their own node. The idea being, that if I can get that migration to show me the extra field I need as a destination, I can then port that effort over to the documents migration and bring the files in as I create the document nodes. Nothing I tried would show me the new field, and I decided that two days was enough time to spend banging my head against this issue for little actual pragmatic gain. I'm going back to importing the files as their own content type.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.