SQL Data Fetcher for CMS
Naming


Variable names should make it very clear what a variable does. One or two letter variables generally don't do that. tb, rR, lI, `lE are all very unclear names.
Do not shorten words in variables if possible. eg limInit, limEnd, rowRes.
Be consistent with your variable names. Either use camelCase or under_score.
your function names are sometimes unclear. What does sqlFetcher fetch that isn't fetched by fetchAllData? Does fetchAllData actually fetch all data? etc.
getResources isn't a very good class name (What is a getResources? ResourceGetter would be semantically better, but still not express what it does very well). Also, what resources? It looks like posts, because post_id is hardcoded (which is odd, since the table name isn't).


SQL


is there a reason for the different getSomething functions? Because it doesn't seem likely that only the title or only the author is needed very often. And a user of this class might think that these are simple getter (as the name implies), while in reality they perform costly database accesses. I would get rid of all of these and return the complete row, ideally wrapped in an object.
Be consistent with your SQL statements. Either SQL keywords are all upper case or all lower case (I prefer upper case).
don't select *, but name the fields you want explicitly.
In sqlFetcher you check $run, which doesn't actually exist.


Your code looks wide open to SQL injection. It is unclear what data is user supplied, but for security reasons I would treat all variable data as user supplied (it doesn't hurt). Use prepared statements with mysqli or PDO everywhere, always.

OOP

Currently, it seems a bit unclear what your class should actually do. Should it be a model that temporarily stores data, as the getter imply? Or should it perform database interactions?

You could easily separate these concerns with a different structure:

class Post {

    private $author;
    private $title;
    // [...]

    public function __construct($author, $title) {
            $this-&gt;author = $author;
            $this-&gt;title = $title;
            // [...]
    }

    public function getAuthor() {
        return $this-&gt;author;
    }

    public function getTitle() {
        return $this-&gt;title;
    }
}

class PostDAO {

    function getById($id, $mysqli) {
        $selectById = $mysqli-&gt;prepare("SELECT author, title FROM &lt;table_name&gt; WHERE post_id = ?");
        $selectById-&gt;bind_param("i", $id);
        $selectById-&gt;execute();
        $selectById-&gt;bind_result($author, $title);
        $selectById-&gt;fetch();
        $post = new Post($author, $title);
        $selectById-&gt;close();
        return $post;
    }

    function getAll($mysqli, $amount, $offset = 0) {
        $selectAll = $mysqli-&gt;prepare("SELECT author, title FROM &lt;table_name&gt; LIMIT ?,?");
        $selectAll-&gt;bind_param("ii", $offset, $amount);
        $selectAll-&gt;execute();
        $selectAll-&gt;bind_result($author, $title);
        $posts = array();
        while ($selectAll-&gt;fetch()) {
            $posts[] = new Post($author, $title);
        }        
        $selectAll-&gt;close();
        return $posts;
    }
}


You can use it like this:

$mysqli = new mysqli(credentials);
$post = PostDAO::getById($mysqli, 1);
echo $post-&gt;getAuthor();

$posts = PostDAO::getAll($mysqli, 5);
echo $posts[0]-&gt;getAuthor();


Now it's very clear that calling the getters does not cost very much (time-wise), and your model can be reused. For example, you might already know all the data without needing a database connection (because they are stored in the URL or session, or because you are performing tests and thus set them yourselves). If you only use the Post class in your other classes (such as the views), it can easily be separated from the database.