CubeCoders is seeking a way to pre-fill new topic forms on their support board with dynamically generated, user-specific content via POST requests, as query parameters are too limited in length. They also want to include attachments. thoka suggests using category templates for static content, but CubeCoders clarifies the content is dynamic and user-specific. thoka then proposes creating a draft via API, but CubeCoders notes users may not have accounts, making drafts unusable — the current redirect flow preserves content through login/registration. merefield suggests creating a plugin if API changes are needed. The core issue remains: no current method supports POST-based pre-filling of new-topic forms with long, dynamic, user-specific content and attachments, while preserving the flow for unauthenticated users.
Right now I’m using the /new-topic?title=foo&body=bar URL to direct users to create a post that has pre-filled, generated content (that varies by user or post) from our application. But I’m limited by the maximum length of a query string so this isn’t useful for anything other than short messages.
Is there any way that this page can either:
A) Accept the fields as parameters in a POST message body
B) Otherwise let me specify the content that the title/body should have when they visit the page that allows for longer content?
@CubeCoders: Was your question targeting “How do I provide a pre-filled ‘edit a new topic’ form to users, extending the limits possible with query parameters?”.
In this case, watching API calls would not help, since that way a topic would already be created.
If you are happy with the same pre-filled text for every user, you could use text in the category template.
@thoka It’s not static content. It will vary by user. The post body is supposed to contain system information which is generated by our application - so we’re having the user redirected to our support board with the information we need pre-filled.
Similarly, being able to include attachments in this way would also be incredibly useful to us.
This doesn’t solve the problem because the user may not have an account so no draft can be created. Using the current flow allows for registration/login while preserving the message once they have done that.