Any plans?
Core is stable enouph for starting...

Comments

Yikes. We'd need a 7.x-3.x stable release first!

Though we could probably start identifying areas of work: the major task I think will be converting various things to configurable plugins: flag types and flag links types.

Are there any roadmap for 7.x-3.{stable} release?
ToDo`s?
I can help with fixing, need this module in 8.x...

Assigned:Unassigned» podarok

looks like we have only 2 release blockers...
following up

Okay, so now we can start thinking about D8.

Though I would still recommend caution: the D8 plugin system is still changing, and that is where the majority of the work will take place.

The plugin system is relatively stable at this point. I'd like to help out!
Would you prefer this happen in a sandbox?

There's still the PSRX file location change to come, maybe though isn't there?
Though I guess if we're using a sandbox we can just move our files around when that change happens.

Some help with the plugins would be super.

I've started work on figuring all this out:

- I've written a plugin type example module to get my head round the plugin type system: #1668362: D8 Plugin Example. There's a few TODOs left there that I'd appreciate pointers on.
- now I've got that figured out, I'm not sure how to have flags be both plugins and config: #2079821: [D8] Flags as plugins / config entities. I'm a bit stuck on this one.

Title:Drupal 8 portDrupal 8 port of Flag module

Just because "Drupal 8 port" in my list of issues is meaningless :)

Suppose better to use sandbox, I'd like to help with some code

Great!

I'm starting with the front-end stuff: #2071245: [D8] Decoupling flag links from Flag. I'm hoping to get that concept to work.

My enthusiasm got away with me and I've already started a 8.x branch in the repo. Sorry!

Mostly it's converting entries in the routing system. I've already gotten parts of the module to work, despite the unstable APIs. I'm more than willing to spearhead the port, and I certainly accept that there'll be more than a little hair pulling (and rewriting) as the APIs change.

Webchick said they needed people to port their modules. That was back in April. I for one, am ready to get my hands dirty.

If necessary, we can delete the 8.x branch in the repo and move it to a sandbox, but I'd rather not. I know I'd rather have a canonical repo than have the ported code floating around in one or more sandboxes.

The routing system has a lot of DX improvements in the pipeline, so it feels very much like a moving target to me.

I'd like us to think more about how the architecture is going to work on D8 -- how we're going to use config entities and plugins. I'd also want to look at whether we can split off the UI: #2071245: [D8] Decoupling flag links from Flag -- but again there we're waiting on potential changes to do with unified entity fields.

(And yes, I'd really rather we didn't have another branch to worry about fixing the same bugs on. If we need a sandbox, we can agree to work on the same one, surely.)

The routing system has a lot of DX improvements in the pipeline, so it feels very much like a moving target to me.

Some, yes. I actually hit one of those already. Much of the rest of the system is still fairly solid and I doubt the controller idea will change *that* much in the future. Everything else I've done is PSR-0 stuff. Yes, there's PSR-4 on the horizon, but that should only mean moving the now organized PSR-0 files into a shorter directory structure.

Personally, I think we should leave #2071245 until Flag 4.x. It's a major enough change that it warrants a major change in version as well.

(And yes, I'd really rather we didn't have another branch to worry about fixing the same bugs on. If we need a sandbox, we can agree to work on the same one, surely.)

Do people really clone the repo and run the module directly from that? As long as the branch isn't tagged, who other than developers would know?

> And yes, I'd really rather we didn't have another branch to worry about fixing the same bugs on

What I mean by that is that right now, if we have a bug, we:

- fix it on 7-3
- hopefully cherry-pick to 7-2, or backport with s/entity/content
- hopefully cherry-pick to 6-2, provided it's to do with Flag internals and not core APIs
- cherry-pick to 6-1 if it works, and otherwise leave it

Now you've made an 8-3 branch, any bugs that crop up on 7-3 we ideally should be first fixing on 8-3. Which doesn't work yet anyway. And is using changing APIs.

What's been done in the past is a big dump commit to get the new branch caught up with all the fixes from the older branch, but a) that won't work because for 8 all the files have moved and renamed and b) it's a total PITA for our version history (I once tracked a bug with git blame or bisect as far as a big dump commit we have in our history where code was copied en masse from something like 6-2 to 7-2. and it's a TOTAL PITA because then you don't have an issue number for the change).

So what I'd like to happen is this 8-3 branch to be deleted, and for preliminary work to be done in a common sandbox, either here or on github.

I do think that #2071245: [D8] Decoupling flag links from Flag is something we can think about now. 8 is going to be such an enormous change anyway.

Okay. Makes sense to me.

Do we have a preference for a D.O sandbox or Github? I could start posting my stuff to either straightaway and then delete the 8.x-3.x branch in the main repo.

Github's easier to set up and tear down.

Though before you push, you should look at #2079821: [D8] Flags as plugins / config entities -- Flags should become config entities + plugins, not handlers.

Done: https://github.com/socketwench/flag-drupal8

I thought it best to be explicit about the version so there's no confusion/hand-wringing that Flag is moving to Github. I haven't yet pushed any code or deleted the branch in the main repo.

Flags should become config entities + plugins, not handlers.

I think you are absolutely right. I haven't yet looked into config entities; that's my day today. 3 days of vacation time left before back to the grind.