Some Great Resources
Archives
Categories
- iPhone (2)
- Learning (40)
- Linux (4)
- Debian (1)
- Mac Terminal / Linux (5)
- Other Stuff (1)
- Programming (63)
- Slim Framework (1)
- Uncategorized (1)
- WordPress (5)
and other things too...
Recently, after setting up another virtual host on my Linux server, for a WordPress site, permalinks were not working. Any page other than home was getting a 404 error. I searched Google for help, but kept finding the same advise, which was basically to make sure that the .htaccess file was writable and had the correct permissions.
Sadly, it took me 2 days to solve this puzzle. (About 3-4 hours total.)
This was the second time I was doing this, so I knew I had figured it out once before, and done all the work to learn how it is done, but for some reason the dots just weren’t connecting for me. It was very frustrating!
So now I am documenting it so that if I ever add another site, I’ll have a guide to remind me of exactly what is required to get it done in minutes, rather than hours.
It was at this point that I realized that the permalinks were not working.
I began confirming that the .htaccess was correct. Then I remembered that I had done something to avoid .htaccess last time because I had read at least one page showing how it negatively affects site performance.
I started poking around the .conf file, adding in the Directory block, and making sure it contained the code that the .htaccess file had.
But the changes were not having any effect. I was a bit baffled as to why.
Finally, I realized that I was not in the right file! Let’s Encrypt creates a second .conf file, and that is where the code needs to be!
The first .conf file has :80 in it, and handles HTTP traffic, and it redirects to HTTPS, so then the .conf from Let’s Encrypt is active. It has :443 in it, and that is where the code needs to be.
I opened up the :443 .conf file from the first site and immediately saw the code I was looking for. A few copy/paste’s later and the new site was working properly, and the mystery was solved.
The :443 .conf file has a Directory block in it, which tells the web server not to look for .htaccess files. This improves performance. All that was required was to copy the .htaccess file content into that section.
Are you also a PHP programmer? I’ve got other blog entries that you might be interested in!
I have been programming for almost 20 years. It all started with Basic and RPG III way back in high school, and have played around with many languages. PHP and Swift my my main languages today.
Some sites I have built:
For fans of BMX legend Scotty Cranmer: https://ScottyFan.com
Meet my Basenji’s Graham and Ginger: https://BarooBoos.com
Meet my newest Basenji, Zulu: https://ZuluJoy.com
When dealing with a model,
all() is a static method.
It creates a new query object, and runs
get() on that object
get() is not static, but can be called statically because of a magic method in the Model class.
You cannot modify the query when using all() .
Model::all() // will retrieve all models
You can select columns to retrieve from the database by passing them as parameters to all()
Model::all('id') // will retrieve all models, but include only the id column
Model::all() and Model::get() do exactly the same thing. The only difference is that Model::all() will create a query builder instance and call get() for you. It does this in a static method on the object.
If you call Model::get() , the magic method will create a query builder instance and call get() on that instance.
Model::all() will only accept columns as parameters. It is flexible and will accept either an array or a list of them.
Model::get() will also only accept columns as parameters. However, it is not flexible, so you must provide them in an array.
Model::where('id',1)->get('id')
This only works because of the magic method. Just like get() , where() is not defined in the Model class.
Just remember that you’re dealing with a query builder instance.