highplainsdesignstudio / hpds-bible Goto Github PK

Currently, the search function only searches through the verses. If the user searched for a particular verse such as John 3:16, the database will return whatever verse includes 'John' or '3:16', but not verse John 3:16 itself. The frontend vue search component can be used to check for regex before redirecting the user. Another route such as /verse and verse search controller will need to be created. The Vue Search Component will redirect to this new /verse route when it detects a verse in the search bar.

I have had to create a new Vue instance for the login form in order to properly authenticate using the Sanctum package. Per the SPA Authentication instructions from Laravel, a call to a specific endpoint must be made. Example:

axios.get('/sanctum/csrf-cookie').then(response => { // Login... });

I will make this call in a Vue instance before displaying the Login Form. Then, the Login Form will continue its current operations. If the user logs in successfully, it is a matter of using axios to make future calls to the api from the main app Vue instance.

The search view currently shows every single result. This should be changed to show only so many results per page.

I tried logging in and it said there were no highlights. I think that the login route needs to change to also return the highlights.

It is possible to send a request to search for blank spaces. This of course causes the database to return upwards of every verse in the Bible. This is a bug that should be fixed.

Test the user registration to be sure that an email verification is sent when a user registers their email. Also, there should be a user interface that the user is directed to when they go to the home page. As it is, the page is blank and serves no real function.

Currently, all of the Vue components are global. This is less than ideal and they should be turned into local components.

I've been implementing the highlights feature using the database. However, due to the nature of SPA's and server calls, the calls to the API are not updating with new information until after the whole page has been refreshed. This is not a good model unless I rewrote the app focusing more on the PHP blade files. Instead, I will focus more on a frontend storage solution using the database as a backup. In this way, a user will use their own storage but will continue to record highlights (and notes, etc. in the future) in the database. This will allow the user to switch devices yet still get up to date records. This will require a bit of extra work, but the backend is already implemented in a way that will work for the time being.

Somewhere down the line in the installation, the data seed for the Testaments table left 4 entries instead of only 2 as intended. The data was duplicated somehow. This should be fixed.

When you make a search and are directed to the results, there is no indication other than the address bar URI as to the search text. The search text should remain in the search box even after search results are returned.

When the search results are returned, the verses do not highlight the searched terms to show the user context. This should be updated to show the searched terms in the paragraphs that they appear.

Right now, there is no design for the leaf components apart from their example creation. A design must be made before it can be implemented. However, in the current state, the app is ready to be used in demonstration again. The setup of my new hardware is complete (personal detail).

When the chapter text appears, there is no way of easily going to the previous or the next chapters. A component for both Previous and Next chapters should be added.

If you try to navigate to a chapter that doesn't exist, you get a PHP error instead of a 404 or redirect. This needs to be changed to something. What that something is has not yet been determined. Either way, Its a bug that needs to be fixed

An enhancement should be added to the project. When a user is logged in, they should be able to see a menu to save Bible verses as they read through the Bible. These verses should then be visible within the user dashboard. Of course, this feature should only be available to users that are logged into an account.

The Highlights model needs to use soft deletes. The migration needs to be updated to add the deleted at column in the highlights table. The post highlights route also needs to update to a soft delete if the highlight is found in the database.

When someone goes to the Bible route, the page is always blank until the user chooses a chapter to read. This is always the case when the user navigates to the Bible route. This should be changed. Every time a chapter is selected, the chapter should be saved to a cookie. In this way, whenever a user returns, the most recent chapter that has been read will appear in the page component.

From the backend, the user will always see the book name capitalized when they navigate to any particular chapter. However, if the user types in the destination as bible.local/genesis/1 (for example), the name of the book will be lowercase per the user's input. This should be updated in the Vue instance to display the name of the book capitalized no matter the user's input.

Per the comment on the Previous/Next chapter enhancement, a Chapters table should be added into the database. This requires that a model be created along with a migration for the table. Also, the table should be seeded within the seeder. The chapters table should include primary id, book_id, book_chapter_#. In this way, the book and its chapter within the book will be associated with a chapter id that id's every chapter of the Bible in order.

If you navigate to the /search route without a 'q' parameter in the url, Laravel throws an error exception. This should be corrected to navigate the user to the /read route.

When the user clicks on the "Read" link from the Home page, the user is taken to the Vue app that expects info from the server to show the contents of a chapter. This page should now be designed to be a landing page that shows the index and whatever else I would like to display in the future.

In app.js in the resources/js directory, the method selectPage appears:
selectPage: function(_book_name, _book_id, _chapter) {}
This method probably does not need the _book_name parameter as it can be looked up using the _book_id parameter. The method would be easier to call from other methods if the book name parameter was removed.

Currently, the dashboard doesn't show any information. This should be changed to show all the registered users. A dashboard controller should be created to control access to such things as users and future data.

When I fixed the issue of the searched verses not showing, I somehow must have broken the search results listing. Now, search results aren't showing!!!!