What to do with my PHP code base?

[gizmola]

Quote

I was aware of those project in 2008.  I simply couldn't understand them, PLUS I wanted the challenge of coding my own site, not "configuring" some framework.

Not understanding -- sure that is an issue for many people.  I will grant you that there is a learning curve, and for many people the big picture is difficult.  With that said, most of these projects had great documentation, and tutorials and demo projects to help people learn them.   

Writing everything from scratch was a mistake, because your site should have implemented MVC to give it a sane and maintainable structure, and you also clearly wrote lots of code that doesn't have a set of robust unit tests, so your site is inherently more buggy and less stable than it would have been if you had used a framework. 

You also reinvented the wheel, big time, rather than concentrating on the important things, as in your business logic ,and the functionality of your site.  To rationalize this decision as a "challenge"  when that challenge did not even include learning the basics of PHP OOP -- is It is what it is, but the path to becoming a better developer is being able to admit you made a mistake.  Most project teams include a post mortem for this exact reason -- to reflect on the process, evaluate what worked and what didn't and hopefully improve.  

 

 

[gizmola]

Perhaps it isn't clear, but with version control, and at this point, the world has standardized on git (for relatively good reasons in my opinion) there is no danger in changing "tested code." 

This assumes that you have a development/test deployment and a production deployment.  If you only have "production"  -- well, it goes without saying that the second you have any actual users, you are in big trouble.

So, I will make the assumption you have a dev/test system, and again, there is no question that you can change anything you want with git, and test things, and you can do these tests with impunity, and without endangering anything in production.

Learn git.  Bitbucket and Github are origin repositories where you can keep a master copy of your code in the cloud.  They are both used by lots of companies, and both offer private repos for no cost.  There are limits to the numbers of people and repos you can have, but in your case either one will be fine.  I have accounts and use both frequently, but my recommendation to you would be to use Github.  Make an account to begin with, and there are a gazillion tutorials, including interactive ones that will teach you the basics.  

[SaranacLake]

On 1/19/2021 at 1:00 PM, gizmola said:

You also reinvented the wheel, big time, rather than concentrating on the important things, as in your business logic ,and the functionality of your site.  To rationalize this decision as a "challenge"  when that challenge did not even include learning the basics of PHP OOP -- is It is what it is, but the path to becoming a better developer is being able to admit you made a mistake.  Most project teams include a post mortem for this exact reason -- to reflect on the process, evaluate what worked and what didn't and hopefully improve.  

What I meant by "challenge" is that A LOT (e.g. 80-90%) of "OOP" developers ALSO don't "get" OOP, and they use frameworks as a crutch, which is why the majority of OOP code out in the world looks like crap and is in fact NOT "OOP".  (Just as "The Gang of Four"...)

I did the best I could with the resources that I had.

i would have given my right arm if I could have "got" OOP, but it wasn't meant to be.

IF I can get my website done, then the next step I hope to take is take one final swing at learning OOP before I die.  😉

 

 

 

[SaranacLake]

On 1/19/2021 at 1:11 PM, gizmola said:

Perhaps it isn't clear, but with version control, and at this point, the world has standardized on git (for relatively good reasons in my opinion) there is no danger in changing "tested code." 

If I had Git and I understood how to use it, you'd be 100% correct.

 

On 1/19/2021 at 1:11 PM, gizmola said:

This assumes that you have a development/test deployment and a production deployment.  If you only have "production"  -- well, it goes without saying that the second you have any actual users, you are in big trouble.

I have "Dev" and "Prod".

 

On 1/19/2021 at 1:11 PM, gizmola said:

So, I will make the assumption you have a dev/test system, and again, there is no question that you can change anything you want with git, and test things, and you can do these tests with impunity, and without endangering anything in production.

Learn git.  Bitbucket and Github are origin repositories where you can keep a master copy of your code in the cloud.  They are both used by lots of companies, and both offer private repos for no cost.  There are limits to the numbers of people and repos you can have, but in your case either one will be fine.  I have accounts and use both frequently, but my recommendation to you would be to use Github.  Make an account to begin with, and there are a gazillion tutorials, including interactive ones that will teach you the basics.  

Learn OOP.  Learn Git.

That is where I hope to be in a couple of months...  ("Learning", that is!)

 

[gizmola]

It does seem that in your mind you build things up to be a mountain, when they aren't.  I don't see using some sort of version control as an option.  It's just the overhead of doing any sort of professional coding.  I honestly don't see how you continue to develop without it (or some other sort of version control).  I don't understand every nuance of git.  I have spent time going over some of the fine points, reading about the internals, and practicing, but for what I need on a daily basis it comes down to a handful of commands.  

Things you need to do at the start.

-Your development and production systems need git installed

-You need to initialize your code base to git.  (From project directory root...)

git init

-You may have to create a .gitignore file to indicate which directories/files not to add to version control

-You have to add all the files (stage them)

git add

-You have to commit your staged files.

git commit -m "commit message"

-You have to create your github repo, and push your files to it.

git remote add origin git@github.com:username/new_repo

git push -u origin master

-At this point you'll have all your files in your private repository, in the master branch.

Just about everything you need to do here is described for you in github.

 

Daily development:

-Decide what you are working on

-Create a "topic" branch

git checkout -b some_new_fix

-Now you are in branch some_new_fix

-change files however you please.  Add files, modify files, delete files.  Test until you are happy.

-Want to review the things you will be changing?

git diff

-Add files 

git add

-commit the changes

git commit -m "Some fixes like..."

-push this new branch to your remote (github)

git push -u origin some_new_fix

-merge changes

git checkout master

git merge some_new_fix

-Push the master branch

git push

 

Your production system should be based on the master branch from your repository.  You would use github as the source by cloning your repo as the production structure.

Pulling any new code into the production master branch is now:

git pull

 

 

That is the basic flow of doing things, with just about all the commands verbatim.  You could make a test repository, play with these commands, push to github, clone the project to a new workstation or subdirectory, etc, and the entire process of doing this and getting comfortable with git would probably take you an hour or 2.