This is probably not something I would be thinking about using as a foundation for future projects, as there are way better, more complete tools for both content management and templating out there that would do a lot better job of separating your content from your template. The two are tightly coupled as it stands now, as a change in either the class or the template, probably necessitates a change in both. That being said, as a way to inject some dynamic content into simple web pages, I think what you have is workable.

As such, I am going to focus my comments not some much on the design here, which I think has some flaws/limitations, so much as on the practical aspects that you as a (presumably) learning programmer can apply to future code.

• Your class is doing too much including: providing site-wide config, getting content for insertion into templates, dealing with user input for parameters passed via GET, sorting list of stylesheets used by the site, etc. As you gain programming experience you will find that classes and methods on classes are best geared to do one specific thing or set of things.
• Your get() method adds zero value. The caller could do the exact same operations against $_GET directly.
• I really like that you are passing the DB dependency to this class. That is a good pattern (dependency injection) to use across a broad range of use cases where a class needs some external dependency. You do however do absolutely nothing to enforce that you are getting a valid object to operate against. You also can't tell what $db is from looking at this code. Is it a PDO object? Mysqli object? Some other DB object defined elsewhere in your system? Someone looking at the piece of code (and perhaps modifying) would have to go back up the call stack to figure out what it is working with here. If for example you are expecting a PDO object (as you are when youlook at calling code), you should a) type hint your parameter as PDO object and b) rename your property $pdo or similar to clearly indicate what dependency is stored there.
• Your PDO database interactions assume happy path execution, doing no validation at all that, for example, statement preparation was successful. This is going to lead to fragile and hard to debug code. Any time you instantiate an object, call a function, etc. you should make sure you understand all the possible exceptions that could be thrown and values that could be returned and make sure you make reasonable provision in your code to handle those cases.
• Don't use 'SELECT *'. It is a terribly lazy programming habit, which makes your code harder to read and understand (what fields do I have to work with?), more fragile (you mean that new field I added into DB broke something?), and can consume more bandwidth than necessary (do I really need to send all this data if I am only using one or two fields?).
• I agree with your comment in constructor that perhaps some of that code needs to go into class methods. I could forse something like this.

• Why is your constructor returning true?
• Be consistent about using either snake_case or camelCase within your own code. I know PHP is bad about this, but it doesn't mean you should be. Develop a consistent coding style. What you have here is lack of any coherent coding style.
• Consider visibility of your properties carefully. You should ask yourself whether something like current page, styelsheets, etc. should be mutable after this object is instantiated. If you don't have a valid reason for allowing calling code to change these values, make the values protected/private and provide getters to allow for reading the data. My guess is that many of your properties should be made immutable.
• Why would you read in and echo out your stylesheet content rather than just providing link to stylesheet, as would be considered best practice?
• I find your template very difficult to read, but this may just be my opinion. While I think it OK to have some PHP directly in-line with HTML (for example for simple variable injections), there are several cases where where you have more complex flow control structures and additional PHP variable prep work that you inline with HTML, making things look cluttered.

This is probably not something I would be thinking about using as a foundation for future projects, as there are way better, more complete tools for both content management and templating out there that would do a lot better job of separating your content from your template. The two are tightly coupled as it stands now, as a change in either the class or the template probably necessitates a change in both. That being said, as a way to inject some dynamic content into simple web pages, I think what you have is workable.

As such, I am going to focus my comments not so much on the design, which I think has some flaws/limitations, but rather on the practical aspects that you as a (presumably) learning programmer can apply to future code.

• Your class is doing too much including: providing site-wide config, getting content for insertion into templates, dealing with user input for parameters passed via GET, sorting list of stylesheets used by the site, etc. As you gain programming experience you will find that classes and methods on classes are best geared to do one specific thing or set of things.
• Your get() method adds zero value. The caller could do the exact same operations against $_GET directly.
• I really like that you are passing the DB dependency to this class. That is a good pattern (dependency injection) to use across a broad range of use cases where a class needs some external dependency. You do however do absolutely nothing to enforce that you are getting a valid object to operate against. You also can't tell what $db is from looking at this code. Is it a PDO object? Mysqli object? Some other DB object defined elsewhere in your system? Someone looking at this piece of code (and perhaps modifying it) would have to go back up the call stack to figure out what it is working with here. If for example you are expecting a PDO object (as you are when you look at calling code), you should a) type hint your parameter as PDO object and b) rename your property $pdo or similar to clearly indicate what dependency is stored there.
• Your PDO database interactions assume happy path execution, doing no validation at all that, for example, statement preparation was successful. This is going to lead to fragile and hard to debug code. Any time you instantiate an object, call a function, etc. you should make sure you understand all the possible exceptions that could be thrown and values that could be returned and make sure you make reasonable provision in your code to handle those cases.
• Don't use 'SELECT *'. It is a terribly lazy programming habit, which makes your code harder to read and understand (what fields do I have to work with?), more fragile (you mean that new field I added into DB broke something?), and can consume more bandwidth than necessary (do I really need to send all this data if I am only using one or two fields?).
• I agree with your comment in constructor that perhaps some of that code needs to go into class methods. I could foresee something like this.

• Why is your constructor returning true?
• Be consistent about using either snake_case or camelCase within your own code. I know PHP is bad about this, but it doesn't mean you should be. Develop a consistent coding style. What you have here is lack of any coherent coding style.
• Consider visibility of your properties carefully. You should ask yourself whether something like current page, stylesheets, etc. should be mutable after this object is instantiated. If you don't have a valid reason for allowing calling code to change these values, make the values protected/private and provide getters to allow for reading the data. My guess is that many of your properties should be made immutable.
• Why would you read in and echo out your stylesheet content rather than just providing link to stylesheet, as would be considered best practice?
• I find your template very difficult to read, but this may just be my opinion. While I think it OK to have some PHP directly in-line with HTML (for example for simple variable injections), there are several cases where where you have more complex flow control structures and additional PHP variable prep work that you inline with HTML, making things look cluttered.

• Why is your constructor returning true?
• Be consistent about using either snake_case or camelCase within your own code. I know PHP is bad about this, but it doesn't mean you should be. Develop a consistent coding style. What you have here is lack of any coherent coding style.
• Consider visibility of your properties carefully. You should ask yourself whether something like current page, styelsheets, etc. should be mutable after this object is instantiated. If you don't have a valid reason for allowing calling code to change these values, make the values protected/private. My guess is that many of your properties should be made immutable after instantiation.
• Why would you read in and echo out your stylesheet content rather than just providing link to stylesheet as would be considered best practice?
• I find your template very difficult to read, but this may just be my opinion. While I think it OK to have some PHP directly in-line with HTML (for example for simple variable injections), there are several cases where where you have more complex flow control structures and additional PHP variable prep work that you inline with HTML, making things look cluttered.

<head>
    <title><?=$ContentManager->pageInfo['title'];?></title>
    <link rel="icon" type="icon/ico" href="/favicon.ico" />
    <?php foreach($ContentManager->stylesheets as $css_file) { ?><style type="text/css"><?=str_replace(array("\r\n", "\r", "\n",

"\t", ' ', ' ', ' '), '', str_replace(': ', ':', preg_replace('!/*[^]*+([^/][^]*+)*/!', '', file_get_contents($css_file))));?>

• You do nothing to sanitize your output from DB against XSS vulnerabilities.
• You do nothing to validate parameters on your public class methods. You should always consider making sure that caller is passing you valid value before working with them.

• Why is your constructor returning true?
• Be consistent about using either snake_case or camelCase within your own code. I know PHP is bad about this, but it doesn't mean you should be. Develop a consistent coding style. What you have here is lack of any coherent coding style.
• Consider visibility of your properties carefully. You should ask yourself whether something like current page, styelsheets, etc. should be mutable after this object is instantiated. If you don't have a valid reason for allowing calling code to change these values, make the values protected/private and provide getters to allow for reading the data. My guess is that many of your properties should be made immutable.
• Why would you read in and echo out your stylesheet content rather than just providing link to stylesheet, as would be considered best practice?
• I find your template very difficult to read, but this may just be my opinion. While I think it OK to have some PHP directly in-line with HTML (for example for simple variable injections), there are several cases where where you have more complex flow control structures and additional PHP variable prep work that you inline with HTML, making things look cluttered.

<head>
    <title><?=$ContentManager->pageInfo['title'];?></title>
    <link rel="icon" type="icon/ico" href="/favicon.ico" />
    <?php foreach($ContentManager->stylesheets as $css_file) { ?><style type="text/css"><?=str_replace(array("\r\n", "\r", "\n",
"\t", '  ', '    ', '    '), '', str_replace(': ', ':',
preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '',
file_get_contents($css_file))));?></style><?php } ?>
</head>

• You do nothing to sanitize your output from DB against XSS vulnerabilities.
• You do nothing to validate parameters on your public class methods. You should always consider making sure that caller is passing you valid values before working with them.