Okay guys, so let me outline the plan for the couple of next videos.
So you know, what features are we going to build and why this would be useful to you.
So my plan is to build, let me call that two features and add one concept.
Let me start with the features as they actually revolve around SQL around writing database queries.
The first is the search feature.
So we are going to add a blog page with all the posts.
And there I'd like us to be able to search by the title and content.
So it might be interesting to see how this can be done, but then we will add another feature on this
post page which is pagination.
This is just dividing the data into chunks of five, 10 or 2 posts per page, which has some goals.
Actually, it will optimize the data fetching so you don't have to fetch everything that you have inside
the database, mind you.
It's possible you're going to write a lot, and you might have a couple hundred posts that might not
be the best choice to to having to always read them all every single time.
And another reason for pagination is the recency.
So I think we should assume that no one really cares about the posts we wrote five years ago.
And the recency is very important.
And the concept that I'd like to introduce is the view partials.
Sometimes we might have some chunks of code that should not really be part of a specific template.
Instead they should be reusable.
In this case, the list of blog posts I think is such case.
It is a good use case for view partials, because we might be displaying the same list of blog posts
on the home page and then on the blog post page.
Okay, so having explained, what are we gonna do next?
Let's jump to the first of those features, which is the search functionality.
So let's jump to the project.
And the first step is inside the post controller.
We don't have any logic at all.
Now I'm gonna just copy paste what we have inside the home controller.
This is just because it would be kind of similar.
So it would give us a quick start.
We just need to remember that we need to change the path to the view.
That's post index.
And inside the views folder we need to remember about creating the index page view which also would
just get everything what we have inside the home index view, only to be modified later.
So to see the difference, I'm just going to say all posts.
So as you see, both pages display the same thing, but well at least we have something.
So now on this post page we should start by adding a form for searching for specific content, right?
Which means this view needs to get a little different.
Before we display the posts, we should add a form.
Now the form needs to have an action.
I will leave this empty, which means just send to the current URL.
If you would skip the action, it would do the same.
And this is what we want.
Also, we want to use the get action so that there will be a URL query parameters, not data sent through
the Post request.
We actually want the search query to be part of the URL.
This will be important later on when we will introduce the pagination feature.
So this input needs to be of type text and the name should be just search.
We might have to provide the initial value but that's for later.
And let's add a placeholder saying search posts like this.
And then let me add a button.
We don't have to specify the type because by default it would be a submit button.
And now we've got another difference that on this post page you can actually search for something.
If I hit search you can see that this parameter is added to the URL.
If I type something like welcome.
This is inside the URL, which is super important because this lets us share the search results with
someone.
I can now copy this and send the link to someone else, and he can also see the search results.
So now we have the form.
Next up, we need to implement the actual logic that will read the value of this search parameter and
apply a specific query.
So back in the post controller, the first thing we should get is the value of this search query parameter.
We can just get it through the super global.
If none was specified, we default to an empty string.
And now let's pass it to the view so that if someone visits a page that had this search parameter in
the URL, it would be populated in the input as well.
Okay, now jump back to the view and let's fill out this value.
So let's do HTML special chars search.
Okay let's try that.
So I'm gonna refresh this page.
And it's not being populated after refreshing.
Okay.
So there was a typo.
The parameter name is search.
After refreshing.
Well it's there.
Okay so we have the search parameter but nothing is happening with it.
That's why we need to jump to the get resent method of the model and make some changes.
At least I think it is a good idea to modify this method instead of creating another one.
So with the changes, I'd like to make this parameter nullable, which would mean it is optional.
Now, this shouldn't be a problem with modern PHP because we can use the named parameters.
And another new parameter here would be search.
It would also be initialized with null.
Now if you skip the limit, you can still search for something or the other way around.
So now we have this simple query.
It might get a little bit more complex.
Okay so let me start by moving the query into a separate string because we might have to construct it
conditionally.
So we will always have this part.
We are selecting everything from the table.
Now let's also create the parameters array.
And the first condition.
So if the search is anything but null, then we need to append something to the query.
So we use the shortcut concatenate equals which would just append to the query variable.
And this something is.
We need to add a word statement checking if the title is like the parameter or the content column is
like the parameter.
Now the like keyword in SQL is for searching for a text within some specific columns.
It lets you use some simple patterns.
Okay, so this is our query.
Now we would have to add something to the parameters since it's empty.
At this point we will just add something.
So I'd like to add the value of search surrounded by Percents.
This means that we expect that there might be something before the search query or after.
That's why we had to add those percent signs.
We don't want an exact match, and we just add it twice because we search both in the title and the
content.
That's why we supply two parameters and that's an equal sign.
Okay.
So we've got the search covered.
And then we add something to the query always because this is ordering.
So we do order by Createdat.
This method is called get resent.
So we always expect to sort using descending order.
And then we check for the limit.
So if the limit is different than null then to the query we add a limit with a parameter.
So this would just limit the amount of results that we receive.
And then we add something to the params.
And that's just the limit.
Now at this point we just pass the query.
And we need to replace this array here with the params.
So maybe we can simplify that and just put everything into one line.
Should be readable and should fit the line.
Okay, so the logic of the model is complete.
Let's go back to the controller.
Okay.
So let's assume that we always want maximum five results.
And here let me pass the search variable.
And then let's see how does it work.
Okay.
So if we search for an empty string.
All posts are displayed if I type welcome.
We've got this post, and this also suggests that the search is not case sensitive because the title
is uppercase and my query is lowercased.
So there is no really a clear button, but if you want to clear the results, you can jump to posts.
So I think this might be fine.
Let me search for tips.
Okay.
One was found.
Do we have anything that will contain the same word?
Let me look for it.
Maybe if I type we.
Okay so we've got two results.
So this confirms that this works fine.
And also you can share this URL with anyone.
And when they visit this page this will give them the same results as we did, which I think is pretty
useful feature when talking about the search.