There are several problems here:
Problem 1: plugin_dir_url
In a comment you mentioned using this code to load the file the class is in:
define("Plugin_root", plugin_dir_url(FILE));
include_once(Plugin_root . 'public/index1.php');
This results in this value being used in include_once:
include_once( 'http://example.com/wp-content/plugin/public/index1.php` );
Which is why you’re getting PHP fatal errors when you try to use the class. It’s very likely if you try to look at your PHP error log you’ll see messages like this:
PHP Warning include_once Failed opening '....' for inclusion
Instead use plugin_dir_path when using require or include.
Or better yet, make it work anywhere with:
require_once __DIR_ . '/public/index1.php';
Since this class needs to be included, why not use require_once instead?
Problem 2: Code is in the Constructor
Code in the constructor runs the moment the object is created, so if you do this:
add_action('admin_enqueue_scripts', $js_scripts = new Public_script());
It’s the same thing as this:
$js_scripts = new Public_script()
add_action('admin_enqueue_scripts', $js_scripts );
Which is far too early, and results in a broken add_action instead do work in a class method/function.
$js_scripts = new Public_script();
add_action('admin_enqueue_scripts', [ $js_scripts, 'your_new_do_enqueing_function' ] );
Constructors are for receiving initial variables and doing any initial setup the object needs to be able to function as an object. Aka dependency injection and initial values. You shouldn’t do work as it makes the object very difficult to write unit tests for, reduces performance, and can cause problems like this one.
Even better, doing it in a more OOP way you would call add_action inside the class, or in an init function:
public function run() : void {
add_action( 'admin_enqueue_scripts', [ $this, 'your_new_do_enqueing_function' ] );
}
$js_scripts = new Public_script()
$js_scripts->run();
The run function can then call all of the add_action and add_filter calls. This is similar to the boilerplate you referenced.
You might see some people call add_action in the constructor, and while this works, it’s not ideal as there’s no way to create the object without also hooking everything in, and no way to let the object do stuff before that happens, e.g. if you wanted to check something first or enable a flag. It would all have to be done in the constructor, and you’d need to know everything before you create the object which makes things difficult if you need information that’s only available after a certain hook, e.g. the is_archive() or is_single type functions
Note that while classes and OOP are useful, nothing you’ve done here is actually object oriented programming, and there’s been a misunderstanding of the WP documentation. WP isn’t recommending using a class, it’s recommending classes as a solution to PHP v5.2 not supporting namespaces.
So for this, you could just as easily use functions and it would use less memory, run a tiny bit faster, and be much easier to understand.
This is not to say that you should never use classes, they’re a tool, and have a time and a place.
If you actually wanted to do something that was object oriented, you’d have built a class that you could create multiple objects with, that wraps commonly used steps to make life easier.
E.g. something used like this:
$a = new AdminAsset( 'js/admin.js' );
$b = new AdminAsset( 'js/admin.css' );
$a->enqueue();
$b->enqueue();
Now we have an actual object that has internal state, and wraps up all the code needed to attach to the admin enqueue hook, figure out the path and URL of the file, register and enqueue it, etc. This example isn’t possible with plain functions, AdminAsset has internal state, and you can have more than one of them.
Likewise you could pass it additional parameters for inline assets, or create an extra function so you could so stuff like $a->add_inline_data( ... ), or functions such as is_enqueued, etc.
You shouldn’t force everything into OO and use classes for everything, that’s a common mistake! Use OOP and classes where it has its benefits and makes sense, there is such a thing as bad OOP, and bad classes ( e.g. look at the google clean code talks on singletons, a notorious anti-pattern that unfortunately is very popular in WP agencies and plugin code ). Also take a look at the difference between pure and impure functions, sometimes a function can be far superior at certain tasks to everything else if it’s written in a particular way
I would also be sure to keep to WP Coding standards, so use a filename that contains the name of the class, use { on the same line not a newline, and add spaces inside parenthesis e.g. test( $var ) not test($var)