Port File (Field) Paths to Drupal 8

See this related Drupal 8 issue:
https://drupal.org/node/2128055

We'll probably have to see what gets into D8 and then compare.

Updated the title so it's clearer when seen outside of this issue queue.

That other issue has been in Needs Review for a year and I have no idea if the changes it make are something that can even get in at this point. I've been tasked with updating this to Drupal 8 for a client so am starting work on it.

Silly d.o bug (#2362065: Sort autocomplete of issue tags descending by usage count *in the issue metadata form*).

This is some initial work including using DMU and my own moving things around and trying to get it fixed up. It's not even close to being usable so I'm not going to bother setting this needs review. I just wanted it up here so it's not only on my computer. :)

Rather than popping up huge patches now and then, I moved this over to GitHub:

https://github.com/MichelleCox/filefieldpaths-d8-port

I've done a bunch of massive changes in the two commits so far but will now try to keep the commits more focused. If anyone wants to join in, feel free. :) Just don't look to me as a leader on this unless you want blind leading the blind. LOL! I'm still very much trying to learn this all.

Still working on this. I just pushed more changes to github last night.

Lots more changes pushed. The module is working pretty well for basic functionality. No bulk updating, yet.

I'd like to get this branch moved to the project here soon. Deciphered, are you out there? Thoughts?

I'll be happy to look into D8 once I've resolved all pending issue in D7 and have a satisfactory suite of tests to ensure sustainable maintenance and portability.

I think it makes sense to keep d8 on GH and move tests from d7
Added link to GH to IS

I added Deciphered to the "Collaborators" on github which should give him access to manage things if I understand right. I haven't used GH very much so I'm a bit of a newb there. If there's anything else I need to do to make sure the code can be used officially, please let me know.

Hi Michelle,

I disagree that GH should be the official repo for D8, and will merge the branch into the D.o branch as soon as I can sit down and audit the port.

I do however already have FFP on Github at https://github.com/decipher/filefield_paths for the purpose of running tests via Travis CI, and that repo will stay in the future.

If you have time, I would suggest forming my GH repo and merging your code into the fork so you can create a pull request for my to review. Also makes the fork easier to track.

+1 to PR and clean up code on gh before pushing to d.o

Ok, I gave it a whirl. I'm not very familiar with GH so not sure I did it right. This is what I did:

- Made a fork of your D7.
- Cloned that locally.
- Made a new branch in there for the D8 port.
- Copied my D8 code over the top.
- Made a commit and pushed it.
- Requested a pull request.

There is still a pull request on my version that needs to be dealt with as well. I haven't had a chance to look at it, yet. That's here: https://github.com/MichelleCox/filefieldpaths-d8-port/pull/4

Thanks Michelle,

I'm unlikely to review the code thoroughly until I've finished my D7 push, and in turn it's not unlikely that my changes will also need to be ported, but hopefully your work will make the port easier to complete.

@Michelle there's a 2nd PR now. Please consider giving me access. I've started to use the module actively for Drupal 8 and will keep an eye on needed changes.

@Deciphered I think you should create a 8.x-1.x branch in github, for such a PR to make sense.

@jonhattan - I don't think it makes sense to have this in two places and Deciphered is the maintainer so if he wants D8 in his repo, we should be working off of that. My lack of knowledge of GH is hindering me here. What is needed so that we can work against Deciphered's repo instead of mine and close mine down? I think at the very least we need to be working off of https://github.com/MichelleCox/filefield_paths/tree/d8port which is the fork and it said when I made my PR that I could make additions by pushing them there. Not sure how all of this works, though.

@Michelle, to work against Deciphered's repo we need him to create a 8.x branch, for contributors to provide PRs against that branch (Your PR can't be merged because it's against the 7.x branch). Since Deciphered has stated several times that he won't pay attention to 8.x port until D7 is fine, I guess this is postponed.

In the meantime we can consolidate the D8 port in your repo. We can continue anytime by IRC if you have any doubt about github.

@Michelle ok I saw you forked from Deciphered's repo. That's fine!

Initial review and clean-up https://github.com/MichelleCox/filefield_paths/pull/1
Let's finish initial conversion at GH, then green tests will allow maintainer to merge

I actually think that module should not use services to alter settings and forms.
Field and storage setting alteration should be consistent.

I set andypost as a "collaborator" on the fork so that I'm not a bottleneck here. I probably won't get contrib time until later in the week. I also changed the link in the summary to point to the fork rather than my initial repo.

@andypost - If you see something that is wrong, feel free to change it. I did the port as I was learning D8 and figuring things out as I went along. The code works (at least with the beta back then) but it may not be the best way of doing things.

I agree that there should be a 8.x-1.x branch, because when it comes down to it, I'm never going to accept the Pull Request because that would merge the code into the 7.x-1.x branch...

As far as multiple developers working on it, it makes sense to fork the fork on GH, fork Michelle's branch and make PR's to her so that when they're accepted they move into her PR to me. The downside is it can cause for some messy commits, especially if things are accepted that I wouldn't have accepted, but given my lack of time I have little right to complain.

Making a 8.x-1.x branch now, @Michelle, if you could kill your PR and make a new one to 8.x-1.x once it exists that would be great.

I looked at this but don't understand what it is I need to do to move the fork over to being forked off the other branch. Sorry, I pretty much never use github so I just am not very familiar with how it works. Maybe it would be better if andypost or jonhattan did it since they seem to know what they are doing?

Hi @Michelle,

It's just the process of creating the PR, when you initiate it it will provide you the ability to chose which base branch to target the PR at:

All you need to do is make sure that the branches are the correct branches.

I've gone ahead and created the PR on your behalf.

Ah, thank you! We use git at work so I'm familiar with the basics but I've never had to deal with forks so I was a bit lost. Glad to see all the movement here. I'm hoping I can join in on Friday. I have some internal time I can use for contrib but sometimes that gets overrun with client needs so we'll see. I'm itching to get back into D8, though. Have barely touched it since the site I did this port for launched in May.

Now that 7.x-1.0-rc1 is out I will be turning my attention to the 8.x port.

Plan at this stage is to simple port the 1.x branch, and then re-write a 2.x branch in the future.

I'd be open to hacking on the D8 port during DrupalCon for those attending.

I have committed a new patch to the pending Pull Request that adds core translation support to the D8 version of FileFieldPaths.

By default, it creates a copy of the original file when saving a translation. While in the future we may want to detect if there are any changes being made to the file path before proceeding with a copy, or perhaps add a configurable option, copying by default is a streamlined answer to immediate usage of the module on a pre-release D8 site.

Additional notes are available on Github.

@Deciphered: Now that RC1 is out, more and more people are going to be wanting to use D8 and are going to be seeing what contrib is available. The D8 port isn't 100% finished compared to D7 but it is at a very usable point. I understand if you don't have time to focus on D8 just yet but I'm wondering if you could just take it on faith that it works right now and get this moved into a d.o branch? If you don't like how it was done, you could always make an 8.x-2.x branch down the road when you are ready to work on it. In the meantime, people would have a usable D8 version for their shiny new D8 sites. :)

While I entirely agree that there is going to be need for a D8 port to be available, I'm not content with the current work that has been done; Please don't let that dissuade you or take that as a criticism, if anything, it's a criticism of my own control issues.

I haven't yet completed a review of the port, but my obvious concern is that it removes the ability to do some of the things that both the D6 and D7 versions do, and I don't mean that they haven't been ported, I mean that the approach implemented actually excludes the ability to do those things.

To ensure that the port is done correctly I have started porting the D7 tests to D8; obviously some of the tests will need to be adjusted for things that have to change in D8, but in general this will ensure that the port works as expected.

As far as just committing the D8 port and doing a correct port in another branch, I strongly disagree with that approach, anything that goes in the 8.x-1.x branch will need to be a true port of the module, anything that deviates from 7.x-1.x will or 8.x-1.x will warrant a new branch.

Again, I want to re-iterate how appreciative I am of the work that has been done so far, and credit where credit is due, it's more than I have done myself to this point. As such, what I will do is I'll make a note on the project page linking to the GitHub repo as an unofficial port with the disclaimer that I can't guarantee an upgrade path when the official port is available, and I will try to re-use as much of your work as possible and give the appropriate recognition.

I hope this is satisfactory.

Beta1 for Drupal 8 is out, all tests ported from D7 are passing, excluding the Find/Replace functionality which was intentionally removed.

This is as much of a straight port as possible, improvements will be made prior to the stable release or in a 2.x branch.