DEV Community: Ravavyr

Logging Logic errors in PHP

Ravavyr — Mon, 13 May 2024 16:10:38 +0000

This is for PHP developers. People writing PHP code and having trouble debugging their sites/apps.

For some reason, a lot of developers seem to have trouble understanding how to add error logging to their applications.

People make it sound overly complicated to implement, and generally want to begin talking about 3rd party services and tools, most of which do not actually tell you what's wrong, but just that there's problems [You don't need to know there's a thousand 500 errors, you need to know WHAT they are, WHEN they happen and WHERE in my code to find them]

What are Logic errors.

First you need to understand what Logic Errors are. The errors that print out and give you a 500 browser response are pretty much all syntax errors. Occasionally you cause timeouts due to bad loops an database queries.
Logic errors are those pesky errors where something goes wrong and you can't see it. OR perhaps it displays the wrong information to the user. Your code is executing fine and doing "exactly what you told it to"...but you told it something wrong and don't know that yet. Hence, a LOGIC error.
Debugging these is the hardest because it requires an understand of the code and finding where to put logs that help tell you something went wrong. An example is, you call a 3rd party API and you always get back a number that you then display. Except one day it returns a letter and your display shows 0 because you're treating it like a number. Nothing breaks exactly, but your info is wrong. You don't know why because you don't have enough validation to tell you it's no longer returning a number.
Having proper validation is the real culprit, but without it logging that something is wrong, you still wouldn't know, and you don't want to be printing out strange messages to the user, so instead I recommend you log it to a text file instead.

So, here's a few simple steps to implement error logging in your custom [or even not so custom] code.

Default Error logging in PHP

If you're running PHP, syntax errors are important to debug. You probably do have Apache error logs already in place. By default they're in something like /var/log/apache2/error.log
You can customize apache's config to tell it to put the logs for your specific site in its own separate log file.
In the VirtualHost directive you can set:

ErrorLog "/whatever/path/you/want/your-custom-file.log"

There's a lot more stuff you can do in Apache conf, but that's a story for another time.
The point here is, you can control where your errors are logged by default, and you should take the time to fix all of them.

Now, this is going to log standard PHP errors, but not your LOGIC errors. Stuff like "if X, great , else error" in your own code.
Logical errors are where most devs pretty much fail completely and their apps are full of problems they can't fix because they know something is going wrong but they have no logs telling them what's happening.

Setup Logic error logs

In your application, setup a directory somewhere where you want to store logs and give it a name like "payments.log" to log errors related to your payments or maybe "users.log" to log errors within your user actions [i dunno, when updating their profile, changing their password, whatever actions], you decide how you want to split the logs, or if you want you can have one file to log it all [not recommended, depending on site/app complexity]

Once you've created that you need to add a logging function that all of your code can call. Preferably you're using classes and objects and you can create a method within each class, for example If you're using a $user object, perhaps you could call it like so $user->log_error("some message");

In the User class you could create a method like so:

public function logError($txt){
    file_put_contents($this->logpath, date('m/d/y-h:ia')." - ".$txt."\n\n", FILE_APPEND | LOCK_EX);
}

The big takeaway is that it's just a simple

file_put_contents()

call with the FILE_APPEND attribute set so it always appends to the file instead of overwriting it, and it has a LOCK_EX attribute so multiple log calls don't overwrite each other and wait until the file is unlocked again.

In between this is the first parameter, the PATH to your log file.
In my implementation i set a class private variable named "logpath", so i can set a different log file for each class or object [this is optional, just set the path to whatever you want]

The second attribute is the message we're logging, and this is where i've automated it to always add the timestamp, so you don't have to manually code that into each log. So your logging just needs to set a message, this little function adds the time and place.

And TADA, you now have a log that stores WHEN an error happens, WHAT the error is [you need to understand your code to say what that is and you can append objects to it using print_r($var,true) so you can log your variables into the log files.

Something i like to do is in my message to put in what line number this is and which file.

An example of a log would be after a CURL call:

if ($response === false) {
    $logtxt = 'cURL error line 138: ' . curl_error($ch);
    $this->logError($logtxt);
}

or within a page. This for example is a scenario where an array should contain items, but doesn't.

if (count($array) == 0){
      $logtxt = 'main error line 26: ' . print_r($response,true);
      $someobject->logError($logtxt);
}

With that i hope that helps you improve your code by having logs for things that "should never happen" but some times do.
And they may help you debug so they indeed never happen again.

Counter-intuitive as it sounds:
Having empty logic error logs is always the goal.

A PHP codebase should have ZERO Errors logged, maybe a few warnings and notices...but never any errors, because all PHP errors can be fixed, often quite easily, so if you have errors, you have work to do :)

There are other ways to do this, i hope this was detailed enough. Let me know if i missed anything or how i can improve it and I'll edit it.

"Attestation check for Topics failed"

Ravavyr — Wed, 24 Jan 2024 22:47:20 +0000

You're going to start seeing this error pop up in the console for pretty much most websites.

Chrome at least has implemented this and it's to support the new "Permissions-Policy" header.
No one knows what it is yet, and no one uses it, so of course they're gonna cram it down our necks until we do.

What it does is let you control which features on the web browser should be allowed for your website. Stuff like camera, mic, geolocation etc.
Here's a nice breakdown: https://www.validbot.com/header/Permissions-Policy.html

You're supposed to decide which of these your website supports and then add them into this new header. Even Security Headers supports this now and docks you the + from your A+ if you don't have it.
https://securityheaders.com

As of this writing it's barely supported by any of the browsers, but will be soon enough and then security folks everywhere will put them on reports that your clients are gonna panic about:
https://caniuse.com/permissions-policy

Luckily it's not as bad as CPS and so relatively easy to define.

Here's a neat Stack Overflow article that shows you how to add it in apache/htaccess or node/express
https://stackoverflow.com/questions/77303375/chrome-browser-error-attestation-check-for-topics-on-https-pagead2-googlesynd

enjoy.

AWS - How to use S3 as a subdomain for static files/assets

Ravavyr — Fri, 27 Oct 2023 21:33:18 +0000

Alright, it's fairly easy to setup S3 and configure it as a static site and put your statis website on it, but to point a real domain to it you can't get HTTPS [SSL certificate] working properly on it unless you follow these instructions:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html#website-hosting-custom-domain-walkthrough-domain-registry

TL;DR on that is that it's a list of 12 steps [each one its own page] that requires you to setup two S3 buckets, use Route53 for the domain, setup Cloudfront and then get a certificate through the ACM (AWS Certificate Manager) in order to get HTTPS working on subdomain.yourdomain.com

So, here's a faster, simpler, and better performing way.

Before we continue be sure you know the difference between "Cloudfront - an AWS service" and "Cloudflare - a separate CDN service"

We all use cloudflare.com for caching, free ssl, free CDN, free bot protection and more...right right? You don't? Get on it.

My steps are as follows:

Get on S3, setup your bucket with the name of the subdomain, eg your bucket name should literally be "subdomain.yourdomain.com"
Give it "public access" [ignore the warnings]
Go to the "permissions" tab and make sure Block all public access is "off"
On that same tab find the "Bucket Policy" and set a Policy for access, so it's not public and only your domain.com can access it, like so:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "Dont Show List", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::subdomain.yourdomain.com", "Condition": { "StringLike": { "s3:prefix": "/*" } } }, { "Sid": "Allow your domain access", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::subdomain.yourdomain.com/*", "Condition": { "StringLike": { "aws:Referer": "https://domain.com/*" } } } ] }

Note: this will now allow anyone to list the contents of your bucket and will only allow requests to load files come from your domain [via HTTPS only]

Register your domain anywhere
Point your domain to cloudflare.com [their walkthrough is simple as heck]
Add a CNAME for your subdomain to point to the S3 URL which will be something like "subdomain.yourdomain.com.org.s3.us-east-1.amazonaws.com"

That's it. Your subdomain will now load your assets from S3, cache them via Cloudflare which automatically handles the SSL for you so HTTPS works out of the box, plus Cloudflare caches your assets [which performs faster than regular S3 requests] and your site's gonna be pretty damn fast.

This is great for sites with lots of mp4s or large images they need hosted. Not only does it perform better than standard S3 requests, it also costs less because you don't have to pay for Cloudfront and the bandwidth usage on S3 is lessened by having Cloudflare do the caching.

P.S. I wrote this shortly after implementing this again today, so i may have missed an item, if you run into trouble setting this up, please reach out to me, I'll be glad to update this with more thorough details to help others out in the long run.

End result, i applied this switch on Oct 27th [the last 3 days on the chart] as a result client now pays $0 for cloudfront. Before it was costing them nearly $20-$30/day.

Cronjobs: WGet versus PHP CLI in the crontab

Ravavyr — Thu, 26 Oct 2023 22:06:43 +0000

TL;DR: Use PHP CLI instead of WGET for your crons!

I've noticed devs using wget for all their crons running in the crontab. I've done it too but i thought about it and the crons running from the CLI are not adding the overhead of making an HTTP request to the server on top of the base request.

I did some googling but could not find one clear answer on how this can affect performance. Lots of SO posts and blogs talking about using the two methods with great examples, but not a single one talked about performance.

So i turned to chatGPT because i too am a lazy developer.

Here's what it had to say:

Yes, there can be a performance difference between using wget and the PHP CLI (Command-Line Interface) directly in the crontab for running PHP cron scripts.

Using PHP CLI:

   0 2 * * * php /path/to/your/script.php

Using wget:

   0 2 * * * wget -q -O - https://yourdomain.com/path/to/your/script.php

Performance Considerations:

PHP CLI:
- Directly executes the PHP script using the PHP CLI binary.
- Usually faster as it avoids the overhead of making an HTTP request.
- Suitable for scripts running on the same server.
Wget:
- Makes an HTTP request to the specified URL, which means it involves additional overhead compared to direct CLI execution.
- May be useful if your script relies on a web server environment or needs to simulate a web request.

Factors to Consider:

Server Environment:
- If your PHP script is designed to run on the same server where the cron job is scheduled, using PHP CLI is more direct and efficient.
- If the script relies on a web server environment, using wget might be necessary.
Overhead:
- Using wget introduces additional overhead due to making an HTTP request, parsing headers, etc.
- PHP CLI directly runs the script without this additional overhead.
Web Server Configuration:
- Ensure that the web server configuration allows access to the PHP script if using wget.
- CLI doesn't have this concern as it runs locally.

Conclusion:

If the PHP script is designed to run in a command-line environment and doesn't rely on a web server context, using PHP CLI is generally more efficient and direct. If the script requires a web server context or if the server environment is different, then wget might be necessary.

It's recommended to benchmark and test in your specific environment to determine the most suitable approach based on your script's requirements and server configuration.
------------------------END chatGPT answer-----------------------

I think it hit the nail on the head, and though i don't have any benchmarks to really compare, i may test it out on some heavy crons i got running and see what happens. It would make sense that removing the HTTP request overhead would cause a small improvement in performance.

I'm not a perfect developer...and neither are you.

Ravavyr — Thu, 26 Oct 2023 21:57:12 +0000

And frankly, we never will be.

I've been coding over 17 years now. Learned html/css/php from kids who were building text-based rpgs in the early 2000s and then got a CIS degree later on [I know, I know, CIS is crap compared to CS for programming, but guess what, no one gives a crap what kind of degree you have after your first job, also, web dev is not programming, but that's a discussion for another time]

I've seen hundreds of sites up close. As in, i setup infrastructure, or a lack thereof, designed and build databases, setup DNS, email, configured servers, apache, node, all that fun stuff. I like to sum it up as "I've seen some stuff".

What I love about this job is that we keep learning. I mean, we literally have no chance of doing a good job if we don't keep learning new things every single year.

When I started out I read maybe 10-20 articles a week. My pet news aggregator now gives me 200-300 a day and I know there's more out there. There's also a lot more filler and just plain bad tutorials out there too now, but there's a lot to learn constantly.

I write bad code. I know I do. But my code works crossbrowser/responsive and loads the correct information.
I also have websites that have gone unhacked for 10+ years, which is damn good as far as a metric goes compared to what I see in the news every week. Granted, few of the sites I've built have been as large as the corporations getting hacked all the time.

I look at it this way:

If you look back at your code from 6 months ago and don't find anything to fix, you haven't learned anything and you are falling behind. Your code may still run fine for many years, but that's not the point right? [some will say it is]

Like any long-lived dev, I've had some sites get hacked along the way. [can't wait to hear from the guys it's never happened to]
My advice is not to try to secure everything [it's impossible else those corporations i mentioned before would not be getting hacked], but make sure you have daily backups and a quick recovery plan and that your clients understand it is possible. I never tell a client their site cannot be hacked, that's ignorant and asking for someone to come along and prove you wrong.

We all learn different ways of doing things and when working in a team have to adapt or fail. Many of us think one way of doing something is the best way to do it. If you've not changed your way of doing things for a few years, you're missing out on different and potentially better ways of doing things.

Learn base languages and structures without using tools

If you're building websites but don't know HTML, CSS, JS, SEO, Structured Data, Adaptiveness/Responsiveness thoroughly but you insist everyone should be using your tools and processes, you're missing things and don't even know it. You don't have to do it all at once, but learn the base languages so when you're using tools you use them the best way they can be used. You shouldn't swing a hammer without knowing how to hold a nail and align the wood.
Remember, it takes years to master any of them, so focus on just knowing enough to get things done at first, that will be enough to land you jobs so you can improve from there.

From devs telling me you "NEED TailwindCSS" or "NEED linters" or "NEED CSS preprocessors" to the few who completely refuse to use any of them out of principle. I've talked to hundreds over the years. Everyone has their own preference, but it's easy to spot the bad devs. They're the ones who think the "one way" they know how to do something, is the "only way" to do something. The reality is everything we do can be done a dozen different ways, some better than others, but with or without analytics/data to back it up no one believes you.

Anywho i wrote this like a year ago, then forgot about it until just now, so here goes, published. :)

What makes a good web developer.

Ravavyr — Sat, 06 Aug 2022 11:57:47 +0000

Years ago I asked a more senior dev "How many good developers do you think there are in the world."
He thought about it for a moment and then said "Probably 5".
I laughed at the time...but the longer I've been in this industry, the more I think he's right.

We all copy code from other sources. We all use google, stack overflow, w3schools, MDN, and other documentation sources that we blindly follow. Often we copy full code libraries into our systems that are completely useless, just so we can use one tiny sliver of its functionality that we should probably have written from scratch.

New developers are taught to use automation as much as possible.
I dare to say not a single newbie React/Vue dev has a clue how to configure a linux server to actually be secure and run a site.
NPM install does it all for them and most hosting services have a one-button install for things as well.

PHP devs all learn laravel it seems and just run composer to do the same for them. Granted they still need a PHP stack so they dabble.

I'm not hating on any languages in particular but merely on the processes we teach the new developers. We teach them so little that when real world problems come to bear, they have no idea how to solve them.

Even with all these tools at our disposal, a great many sites and applications are just atrocious. Broken functionality, broken interfaces, bad user experience plagues us everywhere.
I don't claim my stuff's all that much better, but I know I often try.

So, What Makes a Good Developer...

For a start, languages do not matter. You can learn to code with any language. You can learn to build almost any application with any stack. Some will perform better than others. This is something learn in time, or by googling sufficiently.

I would say our best skill as a developer has to be "how to search using the correct terms that get us to the correct sources of information". This takes time to get good at.

Eventually any developer can learn to write code. Syntax is very similar between most languages and most systems aren't all that complex. Everything uses variables, loops and if statements and that covers almost everything you ever build.

The following items, however, they come with time, and some developers never learn them all, partially because not all developers need to, but I do think most good developers just want to feed their curiosity anyway and end up learning these over time.

This is not for everyone, but these are things I consider vital in a "Good" developer.

Understanding Business objectives [the "WHY" of what you're building and what it means moving forward, learn to grasp what you don't know and predict what's coming]
Performance [how to address bottlenecks, and improve load times if it's an app/website (this is some parts networking, some parts just image sizes, some parts code optimization/refactoring, some parts rethinking your logic), implementing these things during initial development makes live easier afterwards]
SEO [how search crawlers index your content and how to best code for this, or how to block it when necessary. Do this wrong and your clients will rip you a new one if they're a content driven site]
Accessibility [how to write code so disables folks [up to 11% of the population has some sort of disability be it visual, or auditory that you need to understand to write good accessible tools. This should just be standard for any developer nowadays.]
UI/UX [as a developer you should care how users interact with the systems you build and how you can improve their experience. Often it's just dumb things like adding hover/active states, and making sure buttons stand out and are easy to click. Blindly relying on a designer means you're stuck at their skill level. Designers are not programmers and often do not think about how things need to be coded to match the design. Your job is to figure this out and suggest improvements along the way. Most designers are glad to receive feedback and will work with you to do this better. ] Additionally you need to learn this and speak up when a design is obviously bad, or when management makes stupid decisions that hurt performance/functionality/usability. That is absolutely your job and shrugging it off just means you can't take pride in your work.
Administrative needs [The business objectives give you some of this, but once a site/app is built you then need to address the people using it administratively and how you can make things better/easier/more efficient for them which in turn can make or break a business over time. This takes time and frankly most companies don't think about it until years down the road, as a developer you can be the one to guide them to improve their systems]

These are not learned overnight. They will take time and effort, as all things worth doing are. I hope you take them to heart.