Hello,
Is it possible to list all (Rainlab) blog posts for a given user (on a dedicated page)?
Thanks!
as i know, there are component for list but for category, no a custom or related field as author⌠but. there are a simple solution, where you can use code part of page, and use your own logic for fetching posts by author.
example:
Page route: /posts/by/:author where author is slug of username (login field in backend user)
use \RainLab\Blog\Models\Post;
function onInit() {
$this['author_posts'] = Post::whereHas(
'user', function ($query) {
$query->where('login', $this->param('author'));
}
)->get();
}
⌠you can modify this kind of code with your solution as wellâŚ
lil bit strange is, that RainLab.Blog plugin doesnt contain a relation in Backend User to implement $hasMany = [âpostsâ] ⌠
to obtain posts thru User::posts() ⌠maybe a good inspiration for guys in RainLab to create a new component for blogâŚ
But, i think, with Tailor, there will be a way more easy way how to create and implement good solution for article system.
2 Likes
That would be an interesting plugin feature for sure! Thanks for your answer!
The solution by @snipi is good, along with the suggestion to try Tailor (it is much more powerful).
RainLab Blog does indeed capture the author when creating a post. However, there is no option to filter by the author on the front end.
To solve it, a user option must be included in the Post model and scopeListFrontEnd method.
Next, the Posts component class needs a userFilter property, which then passes some identifiers to the listFrontEnd filter.
There is a problem here, though. Exposing the identifier for the administrator is not a good idea. Administrators would need to have a slug field added to their table to reference them in public safely.
So far, we can determine that the âauthorâ of a post is an internal marker linked to a backend user (administrator), and this creates a problem when filtering in the front end since exposing the user ID/login is not secure. This is the reason why it is not implemented already.
However, the Tailor solution included in the demo theme of October CMS v3 has a dedicated author model, decoupled from the administrator model, so this is not a problem. It also includes a page that filters blog posts by the author, ready to go.
Hopefully this helps.
regarding to security vulnerability, maybe there are third way to fix this, and⌠create a new table with separated blog authors without any connection to backend users.
my idea, if rainlab.blog detects existence of rainlab.user, then probably there are some kind of importance to use frontend users to have access to write posts, then authors can be loaded from there.
large resolution may be some kind of all of them
- specific model with admin created authors (Authors)
- rainlab users for frontend (Users)
- any backend user (Administrators/Editors, etc)
dropdown for authors then group by kind of author type
It is good to understand the reasoning behind this feature: to allow publishers only to see posts they have worked on, which we call âContent Ownersâ in Tailor (coming soon).
The design is fit for this purpose, however. It is not designed to be filtered on the front end, so it would need a dedicated author profile model, as we have done with Tailor, but would be a new (safe) relationship.
In the current design of RainLab Blog, âAuthorâ should have been called âOwnerâ⌠It is still open source so you can contribute these ideas. However, Tailor has greater flexibility in its design, so it is probably easier to use that instead.
So a slight adjustment to your proposal, @snipi , make a new model called Author, where the Blog plugin has a controller to manage authors. Authors are hand-crafted profiles and are not associated with any user account. Then rename author to owner, which is associated automatically. The author must be associated manually for every post, with the benefit that authors donât need to have an account, and can technically contribute articles âofflineâ.
1 Like
yup, exactly. fully confirming your points of using tailor and, of course, articles in tailor demo as a main source of idea. maybe, if users upgrade from oc2 to oc3, there may be a one step or something, that will check if system uses rainlab.blog and fire a one step like âwill you migrate blog contents into articles?â âŚ
probably there will be a easier way how to handle and after migration it will ask for removing rainlab.blog as well. but, of course, there may will be some work for admin to replace all components with blog listings, etcâŚ
but, just main idea to asking admin to import all contents from blog to articles.
Do you both mean Rainlab.Blog is not a reliable solution anymore ? I finally found a solution with this plugin, using a hand-defined user slug rather than user login. Does that seem a little more secure?
if you customized user to create a custom slug, then probably it will work for you. both of us only mentoined a posibilities of security leaks etc.