OOP Plugin Development. Including external object

The root of your problem is not object oriented programming, but a fundamental misunderstanding about how PHP handles requests.

If this were a Java or a Node application for example, you would start the application on the server, and it would recieve requests, and respond. It’s a continuous active program. As a result, you can store things in memory and they’re still there when you make another request as they never went away.

That’s not how PHP works.

PHP requests have more in common with AWS Lamda, each request spawns a brand new PHP lifecycle. You can set things in memory but they dissapear at the end of the request, all your objects, your functions, your variables, all of it.

Every new request loads the entire PHP application from scratch. All your plugins, WordPress, your theme, get reloaded every time, then vanish from memory when the request finishes.

So How Do You Persist Things?

The only way to persist things is to use persistent storage, such as a database, files, cookies, object caches, etc

Alternatives include:

• For logged in user specific data use user meta
• For logged out user specific data, use cookies if the server needs access, and JS based local storage for everything else
• For persisting information across multi-page forms, use hidden inputs, there’s no need to persist anything server side until it’s submitted
• For site wide information, use options and transients
• For post specific data use post meta and taxonomy terms
• For term specific data, use term meta

Note that it might be tempting to make use of $_SESSION PHP session variables, but:

• these are vulnerable to session hijacking
• aren’t used by WordPress ( WP uses cookies )
• have to be manually set up and cleaned up
• don’t work with a lot of hosts
• are incompatible with a lot of CDN and caching systems, e.g. Cloudflare
• That data has to be stored somewhere in memory on the server, so this could cause problems with high traffic situations

Some Follow up Notes on OO

1. Use dependency injection! Your object has no business creating other objects in its constructor. Pass them in as arguments. It’ll make your objects more flexible, easier to test, easier to debug, and save a lot of headaches.
2. 1 class per file, don’t piledrive your PHP files. Keep it nice and simple
3. Your IncludedObject might as well just have the public variable, there’s no point in having a getter and a setter if you can just access it directly. Either make that variable private or get rid of those getter/setters
4. Don’t call things “->setXYZ()” etc. Just call it ->xyz(), call it what it is. Why write $person->getName() when you can have $person->name()? Much simpler.
5. The same goes for setters, why have $person->setName() when you can have $person->rename()?

But most importantly, do you really need objects here? Making things OO doesn’t mean that you’re writing better code, it just means you’re trying OO. If your objects have no internal state, and don’t implement any abstract interfaces, then you gain nothing from using classes, and it’s not OO.

Don’t make a huge mess of functions and wrap them in a class and pretend it’s OO, it isn’t, it’s just extra typing for you. So save yourself the hassle. It’s ok for the entry point of your plugin to be a function. It’s ok to put quick filters as plain functions, you don’t have to put everything in a class.

You might be learning, but don’t force yourself to use classes under the guise of “OO”, it isn’t OO, and you’ll just be learning bad habits.