Initially I'd go with ContentRequest -> ContentTweets -> ContentNode -> ContentNodeRevision
:
ContentNode ContentNodeRevision
/ /
ContentRequest --> ContentTweets --- ContentNode --- ContentNodeRevision
\ \
ContentNode ContentNodeRevision
\
\-- ContentNodeRevision
\
\-- ContentNodeRevision
We could eventually skip one level, but would require a self-reference in the revisions table with something like child_revision_id
or parent_revision_id
and will be trickier to pick the current / latests revisions. Harder to maintain and keep up with.
As with any ContentType model, this will hold the specific guidlines for the request:
Field | Description |
---|---|
Handle | Twitter profile where tweets will be published. If available, will be retrieved from Project Profile, so should be in URL format. |
Hashtags | Keywords equivalent. Also stored as JSON Array or simple comma delimited strings. Since it's a bunch of tweets, there's no point in limiting amount. |
Type | Array with one or more from: link, question, quote, tip |
Media | Array with one or more from: none, pictures, GIFs, Videos |
Goals | Array with one or more from: retweets, favs, replies |
It'll be a mutable node which works as an aggregator for copy and media. To be used later on with listicles, FB Posts and maybe even infographics so the user can approve or reject each node on its own. Anything measured by count rather than length.
Would be attached to a ContentNode
in a 1-n relationship. If reduced down to just a plain-text paragraph, could be used for any and many types of content requests. In this case in particular, I cant't think of a tweet needing extra data but the copy body, where all links and hashtags would be, anyway.
If there's a case where we require specific data, then it'll be better to have specifc content type nodes:
TweetNodeRevision
ListicleNodeRevision
InfographicNodeRevision
But I can't think of any of those requiring anything but the text body.
Just like today, Revisions is where all the judging, noting and commenting will happen.
Also a 1-n relation to ContentNode
. Would allow for revisions on media.
Field | Description |
---|---|
Type | Image, YouTube/Embed, Link? |
Description | Useful for early stages, like briefing and concept. |
Path | Image URL, YouTube URL, Link URL |
Workflows should be based on Policies. Since we'd run with generic, reusable models, we could settle on a unified worflow, like first approving copy (ContentNodeRevision
) and only then getting into approving images (ContentNodeMedia
).
But if custom workflows are required, then, again, we should have specific models for each ContentNode
type; or at least extend them from it.
I don't want to do the reusable ContentNode for other content types. I just want tables per content type and model per content type. Shared code can be done with traits. This is mainly because of eloquent and PHP making these things messy over time. Also if we wanted a feature for one revision it would add it for all and if it shouldn't. It will just end up being a mess in some way. This is also why we separated the routes for each content types and have all the components for a content type.
So we change it to be more specific. The other issue here is
ContentTweets
as we never plural models and database tables are already pluralized. Also since we change fromContentNode
toContentTweet
we sould have issues with readability and errors withContentTweets
. So have changed toContentTweetIndex
however if you have a better name then I'm all for it.So when doing this first content type you need to do it standalone, think of just what it needs and do that. Then when we add a second social post type we will refactor the original into traits and interfaces to share all the code and the only part copy pasted will be the tables. As for client side it is fine to do a more generic set of social post components but I recommend doing them just to do with twitter first and then when adding the second type we can rename things to be more generic. Still needs separate routes though, so
/content-requests/:id/tweets
and/content-requests/:id/facebook-posts
etc.With this you need to commit often and ask questions often so you don't get stuck as I still won't be able to help much for a while. Next week I will change sleeping pattern to be online during your days so we can have a big week.