Accessing wpdb (wordpress database) from laravel controller - php

The application I am working on consists of Laravel and Wordpress. I have all the data required in the wordpress database (as additional plugins if need be). I need to be able to connect to the wordpress' wpdb from the laravel controller in order to return the correct view.
however, when I include the wordpress' load.php
(require_once(<wp root>/wp-load.php)
I get the following error when accessing the laravel page:
Cannot redeclare __() (previously declared in /www/laravel/helpers.php:24)
this is because I am trying to use $wpdb to access the DB to get the cotents.
Any ideas on a workaround?

The problem is that wp-load.php boots most of the WordPress framework and WordPress has a function called __(). Apparently, so does Laravel. I tried booting wpdb by itself like this:
include('/path/to/wordpress/wp-includes/wp-db.php');
$mydb = New wpdb('user', 'pass', 'dummydb', 'localhost');
$test = $mydb->get_results("SELECT * FROM {$mydb->posts} LIMIT 5");
But it will throw undefined function errors because it uses functions in the rest of the WordPress code base, which isn't being loaded. That means you aren't going to be able to use $wpdb and Laravel without that function name conflict.
You really don't need $wpdb though, at least I don't know why you would. It isn't really much more than a fairly limited wrapper around PHP's mysql_* functions.
It is a (minor) convenience but that is all. If you have database connection information you can do about the same thing with straight PHP.
If you needed to use WP_Query I'd understand. Some of what it does would be very painful to write by hand.

Related

Calling $this inside Model in Phalcon

I need reanimate an old site, that was made by another programmer a long time ago. The site is built on Phalcon and I don't know which versions of PHP are supported.
I'm seeing many errors like:
Using $this when not in object context
It is triggered because in Models many functions calls core functions of Phalcon like $this->session->get('auth'), but it looks like a new version of PHP doesn't allow it.
How can I fix it without a total rewrite of all models?
Is there any other way to call Phalcon's $this in Model?
Or is it not possible?
If you add variable $di (factory) to your application
you need to write this :
$this->di->session->get('auth');
You are calling a static method, therefore an object has not been created and there IS NO $this.
Static methods are BAD, try and avoid! They're essentially standalone functions hiding inside a class. They're also very annoying to test.

PDO with Drupal 7?

I don't want to use drupal db_ rules.. I'd rather use my own pdo techniques for database queries and updates etc.. But I've managed to be able to get pdo to work, the only issue is that I have to use a connect on every custom page, some users in my community can edit the pages and will be able to see the connection information.. require & require_once do not seem to work.
Has anyone else had this issue and knows how to avoid it?
You could create your own module and use the init hook:
https://api.drupal.org/api/drupal/modules%21system%21system.api.php/function/hook_init/7
function yourmodulename_init() {
// This code will be executed on every page
}
However you should try to use the drupal database mechanics as it comes with a lot of best practices and powerful tools. E.g. views integration:
https://api.drupal.org/api/views/views.api.php/function/hook_views_data/7
In Drupal 7, Database::getConnection allows you to retrieve DatabaseConnection objects for all configured databases. And DatabaseConnection extends PDO so if your really want to bypass Drupal's Database API (which is itself based on PDO and either re-use or extends PDO classes all over the place), you can use it as you would use your own PDO object.
But if user of your community are able to edit your custom page, I'm guessing that your are actually embedding PHP code inside Drupal nodes using the PHP filter. Which is itself a very bad idea (worse than ignoring Drupal's Database API). You should instead consider writing custom modules tailored for your needs.

Joomla External JTable connection

I have a database I need to connect to remotely that is different then the Joomla database.
I can do this easily within other models but JModelAdmin is giving some issues as it seems to require JTable to function.
I have attempted to override the JTable instance to use my external database instead, however it does not seem to want to work and gets an error in "reset". My guess is JTable requires access to the core Joomla tables as well.
Is there any easy way to do this? Or is overriding the core the only option?
EDIT:
To clarify I can get Joomla to connect to the database and run queries. The only problem is that JTable refuses to initialize properly with an external database.
Here is my constructor in my model:
function __construct($config = array()){
$config['dbo'] = TireApiHelper::tireAPIDB();
parent::__construct($config);
}
This works in my list model but not my admin model. my list model has no need for a table class, however the controller needs to use the admin model to publish/unpublish, this is where the issue is. Even though JTable uses the currently set DB instance, it will return false with no Joomla error (according to code I should see a joomla error if $table returns false.
There are several ways you can achieve this, but the key point is to create a new database object. You can find the instructions on how to do that here. Once you have this object you could:
set your JTable class extension to use it via constructor or using the setDBO(...) method. See this.
choose to use this object and a query object without any JTable, like is explained in the Documentation site.
Cheers.

What is the correct location for db object initialization?

I am building a plugin for WordPress 3.3.1. In the code I define several shortcodes, class to support them, and a couple of admin pages. I am at a beginners level with php although I have 20+ years experience with programming, OOA&D, etc..
In the class methods, I make calls to a custom database not housed in the wp database. That is, the custom database is a separate schema, independent of the wp database.
Right now, I make the declaration in the methods that need the object. Works fine for dev but won't cut it in production. I am tempted to raise it to the class instance level. Here is where my question becomes clear. There are several classes that will need the connection. The plugin needs only one connection.
Where is the best place to put the database connection object declaration and initialization?
Given the answer to that, where is the proper place to destroy the db connection object instance?
I would make the database connection a static field. Which class to put it in depends on how you've structured your classes/code. Making it static will ensure that the same connection is shared throughout your script.
I recommend using PDO (connecting PDO to MySQL, etc) to connect to your database. PHP will automatically close the connection when the script ends.

Joomla and MySQL

Is there specific documentation available on Joomla regarding making database queries via MySQL in PHP?
What I'm really looking for:
Whether or not Joomla has it's own database wrapper implemented, and if not, is it recommended to create one using the specified config parameters.
Whether or not Joomla has the capability to parameterize their queries to prevent SQL injection.
Yes, Joomla has it's own OOP defined to deal with databases.
Usually, you will deal with code like this:
$db =& JFactory::getDBO();
$query = "SELECT * FROM #__example_table WHERE id = 999999;";
$db->setQuery($query);
Can read more here: How to use the database classes in your script
Yes, it has its own class, it's the class JDatabase if I recall correctly. There's an API page
where you get all the documented code on the framework.
A this Joomla WIKI, then, you have example on how to use the database class. Don't know if updated to the latest (1.7) version, but I'm pretty sure it works the same (at least did for the 1.6)

Categories