This blog post will highlight some of the bugs within my application, which I encountered during development. These bugs took longer than expected to fix, requiring me to fiddle about with and tweak the code multiple times until a solution was reached.
Bug 1: Correctly displaying the body text of blog posts
Originally, I used the code snippet below to display text from the 'body' column of the posts table within the post show (resources/views/posts/show.blade.php) and home (resources/views/home.blade.php) views.
I didn't realise any issues at first, as the paragraphs generated with faker were short. There was no indication that line breaks were being ignored. However, after creating a longer post myself, which used line breaks, I noticed that these breaks between paragraphs were absent.
To fix this issue, I wrapped the data to be displayed in {!! [data] !!} syntax, which prevents character escaping. However, this opens up the application to receive XSS attacks. To avoid this, the data to be outputted is run through the e() method, which escapes special characters once again. To allow for new lines to be converted to HTML break tags, the output of the e() method is then run through an nl2br() method.
The preferred output appearance is seen in the browser screen capture below.
Bug 2: Displaying an image file from storageThough I was able to store an image correctly using the post create and edit forms, I struggled for a long time to work out how to display them. I tried a number of different paths and combinations of those paths, such as 'storage/app/public/img' and 'public/img'. I'd already implemented a symbolic link between the storage directories (the main storage directory and the storage directory within the public directory). However, I'd made an error creating this link and for that reason, the images I uploaded were not being made available within the public folder via the link.
Due to this error, I spent a large amount of time testing different paths to the images, which would have never worked anyway, as the images did not yet exist in the public folder.
Eventually, I was able to correct my symbolic link, meaning that the images could be accessed using the 'public/storage/img/posts' path (not the storage directory in the project root).
Bug 3: Difficulty displaying the existing tags of a post in the edit post form
When I implemented the tag functionality, I foresaw issues when it came to displaying the current tags of a post within the select menu of the edit form (resources/views/posts/edit.blade.php). I tried a few approaches, one of which can be seen in the code snippet below. This approach displayed the tags currently associated with the post as pre-selected options. All of the possible tags were also displayed (without being pre-selected) below the pre-selected options.
The screen capture from the browser below shows that the approach above was not ideal - it did show current tags as pre-selected, however, it also duplicated these tags later in the select menu. For example, the 'Outdoor' tag can be seen twice in the image below.
To solve this, I decided to show all tags as options in the select menu, but did not include those tags which were associated with the current post. Instead, tags associated with the post were displayed below the select menu. Though perhaps a slight workaround solution, this approach means that users can avoid editing the tags to keep them unchanged. If a user wants to add more tags, they can simply submit the form after selecting tag options from the select menu.
The screen capture below shows the solution above as seen in the browser. This way, users can easily see the current tags and can overwrite them by selecting new tags from the menu.
Bug 4: Page failing to load as pagination isn't implemented correctly
After implementing pagination, I experienced an issue when I requested posts that included a specific tag. This was because the post index view expected a paginated response, however, this was only applied in a standard index request (line 24) without a tag name in the url. The retrieval of posts matching a specific tag name was not paginated (line 21). The screen capture below shows the post controller index function (app/Http/Controllers/PostController.php).
Below is how pagination was implemented in the post index view (resources/views/posts/index.blade.php).
Below is the error as seen in the browser - when a specific tag is requested, the paginate() method was not being used.
This issue was solved by adding the paginate() method to the retrieval of posts, where they were linked with a specific tag (end of line 21), in the post controller.
Bug 5: Images are not being deleted from the storage folder when a post is deleted
I have added this as an edit section in the CRUD functionality blog (6. Implementing CRUD Functionality in the PostController). Images were not being deleted from the storage folder, which was noticed during a feedback session. This bug resulted in orphan files. The code below is the original code from the destroy() function in the post controller (app/Http/Controllers/PostController.php). (Note: this screen capture was taken before having implemented authorisation.)
Below is a screen capture of the updated destroy() function - when a post is to be deleted, I first check if an associated image file exists. If a file does exist, then the image is deleted using the unlink() method. Afterwards, the post is removed from the database. (Note: this screen capture was taken after having implemented authorisation.)
Bug 6: Image caching is preventing new images from being displayed
When testing the functionality of the application, a bug emerged which indicated that file uploads were not working correctly when an uploaded file was being updated. When posts are updated with a new image, the original image is replaced with a new image, but the filename stays the same. New images (old post, new image) would only display on the page if a browser refresh was forced. The code snippet below from the post index page (resources/views/posts/index.blade.php) shows how images were being displayed originally.
<img src="/storage/img/posts/post_img_{{ $post->id }}.jpg" class="card-img-top" alt="{{ $post->heading }}">
This code has been updated to append a query string to the URL, forcing the browser's cache to refresh when displaying an image. This is somewhat of a 'hacky' temporary fix. This approach prevents any stored images from being cached effectively by the browser, which isn't an ideal situation. This approach has been implemented on all pages which display post images.
<img src="/storage/img/posts/post_img_{{ $post->id }}.jpg?v={{ Date("Y.m.d.G.i.s") }}" class="card-img-top" alt="{{ $post->heading }}">
Comments
Post a Comment