Not planned XF 2 - Move $creator->setPrefix($prefixId);

[Snog]

I won't post this in bugs, because it's not a bug but is a serious request.

I'm hoping that setting the thread prefix in both Forum.php and Thread.php can be moved after the custom fields are set.

This would allow me to modify the discussion_open and sticky values directly by extending the creator and editor services for threads based on the prefix.

Without doing that, I need to extend more than just the 2 services. (controllers and service, maybe more, haven't looked closely)

 

[Snog]

Further explanation...

This involves the conversion my Prefix Actions add-on.

With the way things are now, I need to extend the setupThreadEdit, setupThreadCreate and the thread editor service (for moderator apply prefix action) to apply Open, Closed, Stick and Unstick properties for a thread.

If the prefixes were assigned after all other items in Forum.php and Thread.php, I could just extend the thread editor and thread creator services and they would be applied properly.

If I just extend the services now, the options are overwritten by setupThreadEdit and setupThreadCreate because of the current execution order in the functions.

 

[Jeremy P]

You could maybe extend the _save() method of the services and set the values based on the prefix there. That way you're not relying on a certain set order.

 

[Snog]

You could maybe extend the _save() method of the services and set the values based on the prefix there. That way you're not relying on a certain set order.

Good idea! Thanks!

I'll look into it. But I'm not sure how that will pan out with other add-ons. We'll see.

 

[Snog]

Extending the _save() method works quite well. I'm not sure what I was thinking before, but sometimes I tend to over think a problem and get lost.

 

[Chris D]

Realistically we can't necessarily rely on any particular service to run its methods in a deterministic order. For example, although we could indeed change the default usage of this to a particular order, we can't enforce that on others as other developers using the thread creator may decide to run the steps in some other order, either just because it fits what they're doing or because they themselves need certain things to be run in a particular order.

I see you've released the add-on now though and taken the above approach so

Extending the _save() method works quite well. I'm not sure what I was thinking before, but sometimes I tend to over think a problem and get lost.

If you don't over think or over engineer a problem, are you even a developer?