Wedge
Public area => The Pub => Features => Topic started by: dorje on May 12th, 2011, 06:41 AM
-
Well, this is quite a small thing, but important (I think).
In smf there is the createPost function that creates a post and puts the post ID inside the first array passed as parameter. But it doesn't show the topic ID, useful in some cases.
There will be quite simple to modify the function not to return a boolean value, but 0 in case of errors and the topic ID if TRUE.
What do you think?
(off course, I supposed that createPost is still there... If not, delete that post! :ph34r:)
-
I don't get why it would return the topic ID? Seems illogical that a function for creating a post would return a topic ID ESPECIALLY when its primary use is to make a new post. I think I'm repeating myself here...
-
I don't get why it would return the topic ID? Seems illogical that a function for creating a post would return a topic ID ESPECIALLY when its primary use is to make a new post. I think I'm repeating myself here...
I've just ended to implement a system in which a user inserts a new topic in a particular section using the custom form mod. The system than sends a PM (or mail), and I wanted to write the link of the newly started topic... But I miss the topic ID as argument to create that link, the only way is to do a query on smf_messages and select the topic ID. But that means another query, so I guess if using the return of the createPost function can be a good idea, as that change will not affect uses where we expect a boolean value. :)
-
Technically, that's just one extra query per topic created. Right? Isn't that negligible?
-
Technically, that's just one extra query per topic created. Right? Isn't that negligible?
-
I see what you mean, but is it useful to return it?
We might as well return $topicOptions entirely, then... Or whatever.
-
I see what you mean, but is it useful to return it?
We might as well return $topicOptions entirely, then... Or whatever.
-
You know that you pass everything in by reference, right?
Check $topicOptions['id'] on return -- even in SMF. It HAS to know the topic id in any case, if it's a reply, you provide it, even in a new topic, you have to have it to tie the new message to the new topic.
So, not sure what you're asking for that it doesn't already do...
-
I'm too lazy to look into the code right now :P
Still, I added a create_post_after hook in Wedge, and IIRC it has all of the options in it.
-
You know that you pass everything in by reference, right?
Check $topicOptions['id'] on return -- even in SMF. It HAS to know the topic id in any case, if it's a reply, you provide it, even in a new topic, you have to have it to tie the new message to the new topic.
So, not sure what you're asking for that it doesn't already do...
You are right...
So, sorry for the topic and... Thank you Arantor! :)Still, I added a create_post_after hook in Wedge
-
It's listed in the feature list :whistle:
-
I can't remember off hand, but do I take it then that there are two hooks on post creation, one for new topics and one for any new posts? (There was a pre-existing on-new-topic hook that's been in SMF since forever)
-
Nope.
- post creation before (topics and posts alike.)
- post creation after
- post modification before
- post modification after
-
Oh, what about what was integrate_new_topic, then?
-
It's easy to determine if a post is a new topic as well, no?
-
It is, prior to going into createPost. I seem to recall that hook being outside the create function though.
-
No, it was inside.
$topicOptions['id'] has the topic ID but I'm not sure we can determine whether it's a new topic in create_post_after, though. It can be done in create_post_before by testing for the topic ID (empty), but not after -- I think. It may be smart to add &$new_topic as a parameter in the create_post_after (and in create_post_before, in case you want to 'cancel' the new topic status and redirect the post to an existing topic.)
I'll do just that. (Actually, done.) (Just needs to be committed.)
-
Awesome (and a huge improvement)
Thing is, I could have sworn the create-topic hook in SMF was outside createPost because I did SD's equivalent inside the equivalent function and at the time I could have sworn I did so deliberately. But that was most of a year ago I added that integration hook to SD...
-
Perhaps it was outside the function at the time, I dunno ;)