I am absolutely not the target market for this, however I have some comments from what I could look at quickly on a phone:
- a good chunk of data seems to be passed around in associative arrays; It would be much easier to understand, and enforce type safety if you use Model and/or DTO classes.
- you're storing currency amounts using decimals in the database which is fine, but using floats in the app code is a problem. Floating point maths is not precise. Either use integers (and convert to a float for display purposes) or use something like the BCMath extension.
- there seems to be huge swathes of inline styles in your views. This just sounds painful to manage/style/adjust over time.
- best practice is to have a subdirectory which is specified as the docroot and includes just the public assets (images, css, etc) and the front controller (index.php)
- your php code defaults to the currency symbol for Indian rupees but the stripe gateway at least defaults to USD.
That’s seems to have give you a lot of fun and learnings, writing everything by yourself forces you to understand how things work, kudos for that!
The code is very well organized, I’m on my phone and could easily navigate it.
But some stuff twists my nose:
1. No dependencies is cool up to some point, I personally do not try that so I avoid reinventing the wheel. You are prone to have many bugs the community already solved, the trade off end up not being worth the hassle.
2. I see you have many classes but many ones with only static methods. That’s basically global functions that can’t be easily mocked for unit tests and create highly coupled code.
3. Lack tests. Even though you may know the functionality/code from top to bottom, no tests make you prone to break unrelated stuff when writing new code.
Again, nice to see it, awesome you shared! If you want to step up the game https://phptherightway.com/ has a lot of material and references for that.
Im definitely not the target here, but if someone I knew wanted a store and wanted this I would have a few things I would be critical of.
1. no tests, no static analysis.
2. avoiding composer. Why write your own autoloader when Composer can do it, and keep things up to date pretty easily.
3. associative arrays being passed around. There is no type safety on those arrays, and you aren't using a package like PHPStan or Psalm to at least try and enforce _something_ at run time.
4. I find it odd you are anti-composer (one of the best things to happen to PHP) yet tell people to configure a web server with various extensions, permissions, etc.
If I was going to install this, I'd want composer support and tests.
I am absolutely not the target market for this, however I have some comments from what I could look at quickly on a phone:
- a good chunk of data seems to be passed around in associative arrays; It would be much easier to understand, and enforce type safety if you use Model and/or DTO classes.
- you're storing currency amounts using decimals in the database which is fine, but using floats in the app code is a problem. Floating point maths is not precise. Either use integers (and convert to a float for display purposes) or use something like the BCMath extension.
- there seems to be huge swathes of inline styles in your views. This just sounds painful to manage/style/adjust over time.
- best practice is to have a subdirectory which is specified as the docroot and includes just the public assets (images, css, etc) and the front controller (index.php)
- your php code defaults to the currency symbol for Indian rupees but the stripe gateway at least defaults to USD.
That’s seems to have give you a lot of fun and learnings, writing everything by yourself forces you to understand how things work, kudos for that!
The code is very well organized, I’m on my phone and could easily navigate it.
But some stuff twists my nose: 1. No dependencies is cool up to some point, I personally do not try that so I avoid reinventing the wheel. You are prone to have many bugs the community already solved, the trade off end up not being worth the hassle.
2. I see you have many classes but many ones with only static methods. That’s basically global functions that can’t be easily mocked for unit tests and create highly coupled code.
3. Lack tests. Even though you may know the functionality/code from top to bottom, no tests make you prone to break unrelated stuff when writing new code.
Again, nice to see it, awesome you shared! If you want to step up the game https://phptherightway.com/ has a lot of material and references for that.
Im definitely not the target here, but if someone I knew wanted a store and wanted this I would have a few things I would be critical of.
1. no tests, no static analysis.
2. avoiding composer. Why write your own autoloader when Composer can do it, and keep things up to date pretty easily.
3. associative arrays being passed around. There is no type safety on those arrays, and you aren't using a package like PHPStan or Psalm to at least try and enforce _something_ at run time.
4. I find it odd you are anti-composer (one of the best things to happen to PHP) yet tell people to configure a web server with various extensions, permissions, etc.
If I was going to install this, I'd want composer support and tests.