I installed 2 WordPress installations in my site and they share the same database, only, wordpress1 has table prefix of wp1_ and wordpress2 with wp2_ . How can I query the posts from wordpress1(wp1_) to show in the sidebar widget of wordpress2? I can only show posts from wp1_ to wordpress1 (its own table).
It isn't too hard to pull off -- make a copy of the $wpdb object and tinker with it, and wrap calls to the native widget code in that. That is, assuming that the database access credentials are the same. But I wouldn't recommend going this route at all; it is difficult to maintain, and you really should practice proper separation of the concerns. It just takes one slip-up and database A will happily write all over database B.
Have you considered using an RSS widget instead? The http calls could be done over loopback and so shouldn't add much overhead, and the separate databases will remain... separate.
Related
Right now my product related data is being fetched from wp_posts table whereas i want it to be fetched from wpstg0_posts table.
Both the tables are in the same database, i cannot merge the data as it would collide the ID's in both.
Basically I want the products and all the related data to be fetched from prefix wpstg0_ instead of wp_
You Can't Do That™.
Well, you probably could, but you'd break a lot of code in WordPress core, and in the theme and plugin ecosystems. It would take a long time to develop your changes, and you'd be fixing bugs forever. Plus, you would have to backmerge each successive update from WordPress, WooCommerce, and whatever theme and plugins you use.
WordPress and WooCommerce are organized around the uniqueness of post ID values. That is, many features of the meta and taxonomy subsystems use post IDs.
WooCommerce exploits those subsystems to organize products.
You can stand up a different WordPress instance in the same database and give it a different table prefix name.
Are you trying to solve a performance problem? Try putting better indexes on the tables. #RickJames and I have a (free non-monetized) plugin for that. And try implementing a persistent object cache (with redis or memcached).
I want to store some user settings and I thought of 3 options, since it's my first project and I want to start it the right way, I can't figure out which is the the optimal way of doing this..
Storing single settings directly in columns in the user table
Having a user_settings table with the columns setting_name, setting_value and user_id
Storing a JSON string in the user table, in a column named something like "user_settings_json"
On a design analysis, I noticed wordpress stores it in a separate table, but I'm not sure that's necessary for every application (since mine does not have nearly as many user settings as wp does)
I'm using Laravel, PHP, javascript/jquery.
Which do you guys think would be, most useful, overall better, in terms of design, serviceability and performance?
Storing a JSON string ? NO !
You want to be able to isolate the settings, just query what you need. Therefore, keep it in separate columns!
As for the question if you have to make a separate table, no, you don't have to. When you just got some simple settings you can just add the columns to the existing table of users. Be aware of the limitations here. If you do need advanced settings, i would recommend using a separate table. Better do it too early. Not every setting might apply to every user. For example when you've got premium accounts who can have more settings. So, keeping it separate is what I would do.
Btw, I wouldn't let the columns start with 'setting_' if they are already in a separate table containing 'setting' in the name.
Conclusion: Option 2 :)
Recently I've made package for my project which uses Laravel 9 and it allows you to add settings to any Laravel model. It can cast values to primitive types like bool, int, but also to custom classes. Eg.:
$user->settings->get('is_gamer');
$user->settings->set('games_count', 10);
// or global site scoped
Settings::get('display_annoucement');
// more advanced usage with definition of custom class
$address = $user->settings->get('address');
$address->country = 'Poland';
$address->zip = '11-222';
$address->city = 'Warsaw';
$user->settings->put('address', $address);
// any model that implements trait
$article->settings->get('show_breadcrumbs');
$post->settings->get('allow_replies');
You can find it here: https://github.com/npabisz/laravel-settings
Is there a module or set of modules that can be used for this purpose. I process the data using sql scripts etc outside of Drupal. I've read that the combination of Views and CCK could work, but that it involves setting up every single field again (within CCK). I have experimented with using php code within blocks, but the display options are limited. Will I have to create a new module?
Using CCK for this is a really bad idea.
CCK can only deal with the exact database architecture it creates. It is near to impossible to use existing CCK fields on an existing database architecture.
CCK changes the database layout, based on its configuration. E.g. making a field "multiple", or re-using a field on another content-type will drastically re-order and normalize the database: creating new tables, removing columns and so on.
Your external script would need to take all this into consideration. The only proper way, would be to process everything trough the CCK API, which involves writing cron-implementations or drush scripts.
This leaves you one really nice option: Make a module, which defines its own content-types. Such a module gets the opportunity to define all the fields (no CCK, just $node->foo) in any way it wants.
This is a good pattern to e.g. create nodes that have content from external services. Say, a $node->price field, where the price is retrieved from some external SOAP service.
This is also a good pattern when you have legacy databases, where you need to read, write or update data from.
Another benefit of this approach is that you can easily limit the actions: e.g. readonly, or create&read but no update. CCK does not allow such things (easily).
I am building an application using the latest copy of Codeigniter 2.0. My application is dynamic and is kind of like a custom CMS I guess you could say. I have a database table called 'settings' with the following fields:
id
name
value
Basically what I am currently doing is using a helper function to retrieve specific settings from my settings table like the site name or current theme. However I've started thinking that maybe the constant amount of database calls for retrieving settings is a bit too much on the database.
Is there a way of retrieving settings for my application from the database and then appending them to my configuration file? I've noticed Mojomotor does something similar and it is a CI 2.0 application, however I would much rather the simplest and easiest code to do so.
I would preferably like to be able to check every so often if a setting in the database has changed and update the configuration file. The less strain on the database the better.
The best solution lies in the middle. Not zero DB calls; and not one DB call per setting. Do one DB call per page load instead, and get every setting in a recordset / object that the rest of your app can refer to as needed.
I am creating a CMS and am using serialize to handle publish and rollback, which seems to work fine. Basically, The normal site tables are what gets displayed and anything not displayed is serialized in a separate table. The problem however is in making the 'Preview' functions work.
Since the front end is created using normal SQL calls, and all the pre-published/rolled back data is in a separate table it would mean updating every sql statement with some fancy code to pull the version correct to the preview. It will also get especially problematic with things like limits etc and would be a nightmare for the front end.
The only other approach I can see is a separate database/table(s) for the preview copy, but many people may be using the preview function and I am loathe to create a duplicate database for every person using preview as it will very quickly get out of hand.
Is there any way of doing this that will allow preview, and rollback preview, but will not require much from the code that displays the contents of the database and also avoid the problem of mass duplication?
I'm not sure that storing your content data in more than 1 table depending on its state is the way to go.
I would store every version of the content in the same table, having a field which purpose would be to set the state of the content (old version, current version, currently being edited, whatever you want depending on your content editing workflow). That kind of status field plus a date date, would make your content versions way easier to manage.
I used this method for various applications, and was always satisfied with how easy it was to implement rollbacks, previews and even more complex stuff (cvs-like pseudo-branches, ...).
What eWolf means is that when you have a seperate model and view you can have your model supplying different data to the view and then you don't need to copy your database, but instead simply create a standard and a preview model.
The preview model doesn't have to make queries to the database but instead delivers the data that you store in it before passing it to the view.
Consider this example:
//in the controller:
$previewPage->setTitle("foo");
...
//in the view(when previewing):
$previewPage->getTitle(); // returns whatever you stored beforehand
//in the view(regular viewing):
$livePage->getTitle(); // queries the database and returns the result
To learn more about the Model-View-Controller pattern you might want to check out this article.
I hope that helps.
If you seperate Model, View and Controller, this should be no problem: You just take the model from somewhere else in the controller and pass it on to the view.