Posts and Comments
All posts are visible on home page for all users to click and view.
Home page showing all posts:
View for posts page:
View shows the user the welcoming banner and all posts. It does that by using @foreach method which presents information of every post existing in posts table. Those information are post's title and its thumbnail picture.
@if (session()->has('success')) looks for a success message during session management and when it finds one it displays it (regarding new account creation, logging in and out).
After clicking on a post title, user can view the description of the post and leave comments (if he isn't a guest user).
Comments
Chosen Post page:
View for single post with its comments:
Here again thanks to @auth we can allow only logged in users to add new comments.
@foreach ($post->comments as $comment) displays all comments that were written for current post.
{{ $comment->author->username }} using the Comment Model, we use the author() function to connect the user_id of the comment to id of the user who is this comment's author (parent). Then it shows that author's username.
format('j F Y, g:i a') this format means that the comment creation date and time will be shown in this way:
Arrays with two word types were created, one for banned words which is $org and one for words that should replace the banned words if they wil be used in the comment $rep.
$art = request()->validate([ 'body' => 'required' ]); states that all $art array elements taken from user's request (here body for comment creation) should be validated.
$art = str_ireplace($org, $rep, $art); replaces bad words ($org) with good words ($rep) used in any of an $art array elements (in this case there is only a body).
$post->comments()->create([]); uses Post Model to create comment using the comments() function.
'user_id' => request()->user()->id requests an id of an user that is creating given comment.
'body' => $art['body'] takes the purified body value from user's input and saves it in comments table under the 'body' column.
Appeared problem and its solution
To apply this simple purifying method of bad words for good words replacement I had to somehow pass user's input thorugh word replacement stage and then pass it over to comments table as a 'body'. Stating it just as 'body' => request('body') was indeed posting the comment but didn't purify the body input. At first I tried to do that: 'body' => $art but an error occured saying that I'm trying to convert an array to a string, which I realised was true. I couldn't pass whole $art array as just one table column even if an array had only one element as the system would never allow or understand it. Instead I had to specify that one element like that: 'body' => $art['body']
Posts Management
As I previously mentioned, all admins can also manage posts from their dashboard. They can create new posts as well as editing and deleting already existing ones. They have a table with posts list very similar to the one showing all users.
Post Management Page for admin's dashboard:
View for that page:
This view consists of table showing each post record and information about it (post id and title) as well as options for editing chosen post or deleting it. At the top of the page there is also an option to add new post.
View of new post adding page:
enctype="multipart/form-data" is used as the form includes <input type="file"> element for adding a thumnail image of the post.
The form requires an admin to write in the title, body (post description) and add a thumbnail picture.
Adding new Post Page (only accessable by admins):
Controller for adding new post by admin:
Posts adding controller uses the same bad words prevention mechanism as comments controller.
'thumbnail' => 'required|image' states that thumbnail file uploaded by admin creating the post, has to be an image file to pass the validation.
As we can see it works as I can't submit files other than image files types. Request will only accept jpeg, png, bmp, gif, svg, or webp files.
Post::create($attributes); uses Post Model to create new post in posts table.
Appeared problem and its solution
I wanted my thumbnails to be stored in the public folder inside the storage, so I applied this code:
$attributes['thumbnail'] = request()->file('thumbnail')->store('thumbnails');
I also stated that I want to use the public directory in the configuration file called filesystems.php:
Unfortunatelly it wasn't enough and for some reason my thumbnails folder was getting created outside the public folder which made it by default not publicly accessible. To fix it I specified the public disc again in the store function of thumbnail storing line of code:
$attributes['thumbnail'] = request()->file('thumbnail')->store('thumbnails', 'public');
It worked and the thumbnail folder contents were now publicly accessible.
Edit Post View (accessable by admins only):
The view for editing a post looks almost the same as one for adding it. The difference is, that in the inputs it shows current values of those elements, so if the admin wants to only change one of the elements, or just one word or a letter, he doesn't have to retype everything from scratch.
This is done by adding this to input settings: value="{{ $post->body }}" (in this example input for body element). The thumbnail isn't required as well, as admin might not want to change it at all.
Edit Post Page:
Controller for Admin Post management (list view, editing, deleting):
All the functions and paths for them included in controller are secured with authorization condition, that those functions are only accessable by admins (is_admin >= 1).
'posts' => Post::paginate(50) shows first 50 records from posts table (wanted to include that here as a reminder because pagination might be useful in future development), as I wanted admins to always see all the records are changed that line to 'posts' => Post::all()
Editing post is also using purification system that changes bad words for good ones.
Appeared problem and its solution
I wanted to get rid of orphaned images in my thumbnail folder. It means, that whenever an admin will delete a post or change its thumbnail, the image without a parent (without post it belongs to) will be deleted from the app storage, and not only from database.
To do that, I had to add those two lines of code:
First line will see if after a record update, a thumbnail still belongs to an existing post id or if it isn't replaced by other image that will now respond to that post id. If the thumbnail happens to be an orphan, it gets deleted from the public storage disk.
web.php with routes for all of the above functions and views:
get - this method allows us to display a view and showing some data taken from database
post - this method allows us to take data from user's form inputs and store them in database
delete - this method allows us to delete records from the database
patch - this method is used for updating chosen database data
Komentarze
Prześlij komentarz