How to make sure changes to a Wordpress plugin won't be lost on plugin update? - wordpress

I'm pretty sure I've read somewhere that you can actually move the main plugin *.php file to somewhere else (I assume under your theme directory) to have it safe in case you made changes to it and your plugin updates. I tried Google but I can't find anything. Google page with good results will suffice.
I've just experienced a situation where my 2 plugins which had its layout changed and accommodated my needs and I want to make sure it doesn't happen again. Apart from having the main file in another location, is there a way to move along any CSS and JS files as well?
In Concrete5 CMS there is a nice way of doing this, by creating a new folder inside a block of an addon (may be regarded as a WP plugin), inside of which you can create copies of main file, any CSS and JS files and then you can simply edit them and choose that template for a page location you are using that block in.
I assume there is no such thing in Wordpress but how close can I get?
UPDATE: I found where I applied that advice on creating a new instance of the file then moving it to the theme directory.
The plugin in question was HL-Twitter. These are the plugin files:
admin.php
archive.php
functions.php
hl_twitter.php
hl_twitter_archive.php
hl_twitter_widget.php
import.php
widget.php
Now, this is the top contents (commented out) of the hl_twitter_widget.php:
Widget Theme for HL Twitter
To change this theme, copy hl_twitter_widget.php
to your current theme folder, do not edit this
file directly.
Available Properties:
$before_widget
$after_widget
$before_title
$after_title
$widget_title
$show_avatars
$show_powered_by
$num_tweets: how many tweets to show
$tweets: array of $tweet
$tweet: object representing a tweet
$tweet->twitter_tweet_id
$tweet->tweet
$tweet->lat
$tweet->lon
$tweet->created
$tweet->reply_tweet_id
$tweet->reply_screen_name
$tweet->source
$tweet->screen_name
$tweet->name
$tweet->avatar
$user: represents the Twitter user (ONLY SET IF SHOWING A SINGLE USERS TWEETS!)
$user->twitter_user_id
$user->screen_name
$user->name
$user->num_friends
$user->num_followers
$user->num_tweets
$user->registered
$user->url
$user->description
$user->location
$user->avatar
So I was wrong about copying the main file (in this case hl_twitter.php), but still - this enabled me to edit the file outside the plugin directory and the system somehow checks for its existence and picks it up if exists.
If this behavior something that is natively supported by Wordpress or it has been integrated in the plugin itself?

With themes, Wordpress has a concept of "child themes" which allows exactly that: to keep changes separate from main theme, in case it changes.
I haven't yet found a way to do this with plugins.
I'm using a few tactics myself:
I bump plugin version to a very high number like 99.9. This way Wordpress won't ever update the plugin.
Store my plugins in version control (i use git, but it doesnt matter), this allows you to update the plugin, run the 'diff' tool and see what changes happend. If you don't like you just revert like it would be a bad code you've written. But this approach requires a bit of skill.

Are you talking about running parts of a modified 3rd party plugin, and an updated version, at the same time?
That's not going to be possible. There is no magical method of "preserve my changes and transfer them into the new version automatically". The way to go here is doing a diff between the edited version and the update, and integrating the changes in the actual source files.
The bottom line is, if you manually edit a third party plugin, you're in for manual review (and possibly rework) once an update takes place. That's why it's usually not a good idea to extensively modify third party plugins.

Well in fact, yes! There is some kind of way.
You have to remove the to be modificated plugin's original actions/filters and then add your altereted actions/filters.
If the desired plugin is even coded in OOP you can just inherit the whole class and rewrite the wanted functions (oh sorry: "methods". we're talking about OOP ;) ). Instantiate your inherited class and rest as above.
Maybe there are better ways! I already search for a method so that the original class won't even get loaded but our altered one instead but I'm no John Carmack.

Related

FuelPHP to WordPress

We were tasked to integrate fuelPHP to run in WordPress Website to gain the advantages these two offers to developers. We've been looking for methods over the internet on how to do it and we came to this site.
We followed all the instructions, Yes, it successfully installed wordpress but failed to integrate with FuelPHP, when we tried to open fuelphp, it returned an error:
Fatal error: Cannot redeclare class Fuel\Core\Autoloader in
C:\xampp\htdocs\game-bootcamp\fuel\core\classes\autoloader.php on line
24.
is there somebody there who successfully do it? Can you give us instructions on how to do it?
Excuse me for answering an old question, however it is not answered anywhere on the internet. This is important question because Wordpress is good for end-users, and Fuel PHP is very fast & good for programmers.
You can integrate Wordpress and Fuel PHP in two ways.
Wordpress to run in Fuel PHP
Fuel PHP to run in Wordpress
The first way
I bet you asked for the second one however you posted a link to tutorial for the first one. I can give you answer only for the second one.
Generally, the first way will be probably painfully, however here is some tip to get you started.
Wordpress Codex - Integrating Wordpress with Your Website
This way you can probably override using Wordpress themes and outputing anything and let the Fuel Request take the lead using Wordpress query functions. It seems as good way to integrate if you want Wordpress panel and Fuel PHP display, I don't think it's good idea at all, but if you want - go for it.
The second way
I wanted to achieve backoffice panel based on Fuel PHP and Wordpress website with the data taken from this backoffice panel with Fuel PHP classess inside Wordpress code.
This way you should leave the Wordpress application routing as it is and take advantage of HMVC pattern of Fuel PHP.
I have found this one which gave me the overall idea how to make this:
https://github.com/robertosobachi/wp-fuel-framework
Step #1 - Wordpress basics
Do not modify Wordpress core. Do not modify Wordpress themes. Either create your own child theme or your own theme. If you want to make everything right - you should create Wordpress plugin for that.
You can then integrate Fuel PHP in functions.php file, however the best way is to create your own theme with Sidebar (Widget) Areas and create plugin which will make use of either theme-defined sidebars, defined PHP functions or/and shortcodes.
In your theme/plugin code you need to load Fuel PHP. You can make it on Widget Init action however it's your choice where to load this exactly.
The code below is for Fuel PHP 1.8, however you can probably go with further versions following this steps.
Step #2 - Fuel index.php duplication
Let's assume following folder structure:
/apache/www/backoffice/ (with fuel and public folders)
/apache/www/wordpress/ (with wordpress)
Open the /apache/www/backoffice/public/index.php and see what's going there. The first thing to do is to duplicate the steps Fuel is doing but within Wordpress. Every code I paste should be placed in your Wordpress plugin or theme (as you like). ABSPATH is defined by Wordpress.
$dir = realpath(ABSPATH.'../backoffice/public');
define('DOCROOT', $dir.DIRECTORY_SEPARATOR);
define('APPPATH', realpath($dir.'/../fuel/app/').DIRECTORY_SEPARATOR);
define('PKGPATH', realpath($dir.'/../fuel/packages/').DIRECTORY_SEPARATOR);
define('COREPATH', realpath($dir.'/../fuel/core/').DIRECTORY_SEPARATOR);
Now you can copy the rest of Fuel index.php:
defined('FUEL_START_TIME') or define('FUEL_START_TIME', microtime(true));
defined('FUEL_START_MEM') or define('FUEL_START_MEM', memory_get_usage());
// Load in the Fuel autoloader
if ( ! file_exists(COREPATH.'classes'.DIRECTORY_SEPARATOR.'autoloader.php'))
{
die('No composer autoloader found. Please run composer to install the FuelPHP framework dependencies first!');
}
// Activate the framework class autoloader
require COREPATH.'classes'.DIRECTORY_SEPARATOR.'autoloader.php';
class_alias('Fuel\\Core\\Autoloader', 'Autoloader');
The rest of the index.php code is based on the Request class which we don't want to use now, so do not copy it. However you can see the line:
require APPPATH.'bootstrap.php';
Let's go to that file. Inside in the first lines you can find:
require COREPATH.'bootstrap.php';
So let's start with this one first.
Step #3 - CORE bootstrap.php duplication
It is save and probably required to copy the first lines of this file.
define('DS', DIRECTORY_SEPARATOR);
define('CRLF', chr(13).chr(10));
define('MBSTRING', function_exists('mb_get_info'));
require COREPATH.'base.php';
setup_autoloader();
get_composer();
Do not copy register_shutdown_function, set_exception_handler, set_error_handler unless you know what you are doing. You probably want to use default Wordpress error handling. Use fuel error handling is very tricky to do however if you want - try it. Personally I gave up.
You have to copy the setup_autoloader and get_composer functions. They are long, but they are crucial to make this integration works. I didn't copy it here to make this post more readable.
Step #4 - APP bootstrap.php duplication
Hope you are not lost yet. We have to go back to APP bootstrap.php and copy this lines.
\Autoloader::add_classes(array(
// Add classes you want to override here
// Example: 'View' => APPPATH.'classes/view.php',
));
\Autoloader::register();
\Fuel::$env = \Arr::get($_SERVER, 'FUEL_ENV', \Arr::get($_ENV, 'FUEL_ENV', \Fuel::DEVELOPMENT));
\Fuel::init('config.php');
I am not sure if Fuel::init is so much important to load, haven't tested it yet. However you must be aware that Fuel::init method is setting some global variables like date_default_timezone_set (according to the config) so it can somehow modify the way Wordpress is working.
So, that's it. Now within your plugin/theme file you can make HMVC requests to your Controllers. You can access your models, Fuel classes - just like you used to do. Do not forget to activate your plugin in Wordpress.
$widget = Request::forge('widget/sample')->execute();
You have to be aware that it's not echoing the view automatically - see Fuel documentation for more.
Here is the pastebin: link
EDIT:
There is another tricky part I found using sessions: when you are using only HMVC requests the Session is not saving so you have to call Session::write() manually within your code (wherever you want to save it). You will have to call it before the Wordpress output is made so try to hook to init or just place it in your main plugin file.
EDIT #2:
There is yet another tricky part with Wordpress auto "magic_quotes_gpc" feature. Do not simply turn this off by $_POST = stripslashes_deep($_POST); as it may break Wordpress security. The better way is to stripslashes right before adding to the database within your Fuel code and only those variables that you need to strip.

Trying to override templates in FOSUserBundle, but having no effect

I'm trying to modify the skin of the register.html.twig template found in FOSUserBundle/Resources/views/Registration/register.html.twig.
I've basically followed the instructions in the documentation down to a T.
Like it told to do so, I created /app/Resources/views/FOSUserBundle/views/Registration/register.html.twig.
Cleared the cache (and browser cache just to be sure)
NO effect! I've put a blank file in register.html.twig, but no matter what I put there, when I go to /register/, I still see the default template.
Yep, these things happen all the time.
It should be:
/app/Resources/FOSUserBundle/views/Registration/register.html.twig
Reference

Template files not being discovered

I was experiencing an odd problem where blocks were not showing up on a site. After a lot of spelunking I have found that block.tpl.php is not getting called/discovered.
Looking at the suggestions that the theme engine is trying to find it looks like the most general template it will look for is block-MODULE.tpl.php - ie if I set up symlinks for block-block.tpl.php, block-views.tpl.php etc then the content will show.
It just won't find block.tpl.php
So I can kind of make the problem go away, but I'd feel a lot better if I could fix it properly.
Anyone know why (or where) this would happen?
This is drupal 6, with a zen subtheme. zen is in sites/all/themes/ the subtheme is in sites/example.com/themes/.
(it does seem to be finding page.tpl)
PHPTemplate will find the more general templates (e.g. block.tpl.php): you can confirm this behavior by looking in the themes/garland folder which has its own block.tpl.php.
The most common reason for the template engine ignoring your template overrides is because the theme registry has not been reset. You can reset it by going to Site Configuration -> Performance and clicking Clear cached data at the bottom of the page.
Also make sure you've gone through and followed the instructions for sub-theming exactly: missing a step can produce unexpected results:
How to build your own sub-theme (6.x-2.x)
How to build your own sub-theme (6.x-1.x)
Turns out I had added a to the hook_theme() function in template.php for blocks that was pointing to a different location and confusing everyone.
Why I did that is lost to history, but it seems to server no useful purpose.
there should be a version of block.tpl.php in both the theme and subtheme directories.

How does one inject variables into page templates from a custom Drupal module?

We've created a custom module for organizing and publishing our newsletter content.
The issue I'm running into now -- and I'm new to theming and Drupal module development, so it could just be a knowledge issue as opposed to a Drupal issue -- is how to get each newsletter themed.
At this point the URL structure of our newsletter will be:
/newsletters/{newsletter-name}/{edition-name}/{issue-date} which means that we can create template files in our theme using filenames like page-newsletters-{newsletter-name}-{edition-name}.tpl.php, which is great. The one issue I'm running into is that all of the content comes through in the $content variable of the theme. I'd like to have it come through as different variables (so that I can, inside the theme, place certain content in certain areas.)
Is there a proper way for doing this?
Edit: To answer some questions: The issue is a node (there are issue, edition and newsletter nodes) and the path is being set using hook_menu with wildcards and a router.
The best answer I could find was to add a check inside of phptemplate_preprocess_page to send the vars back to the module and have them be updated.
Like so:
function phptemplate_preprocess_page(&$vars) {
if (module_exists('test_module')) {
_test_module_injector($vars);
}
}
then in my test_module.module file I created this function:
function _test_module_injector(&$vars) {
$vars[] = call_to_other_functions_to_load_vars();
}
It seemed to work. I wish there was a way to do this without having to touch the theme's template.php file, but otherwise this works well.
If there were better documentation for template preprocess functions, Drupal would be a lot more accessible - as it is, you need to piece together the information from a lot of different explanations. One place to start is here:
http://drupal.org/node/223430
but if you take the time to work through the tutorial below, you'll find you can do most things:
http://11heavens.com/theming-the-contact-form-in-Drupal-6
This is an old post, and the OP's issues seems to have been solved.
However, just for others finding this through Google (or otherwise):
Install the 'Devel' module: http://drupal.org/project/devel
Also the 'Devel Themer' module: http://drupal.org/project/devel_themer
Use Devel Themer to go through the $content variable and find what you need to pull out.
There are a bunch of Devel/Themer docs/tuts out there, but its usage is pretty straightforward. Note, though, that some stuff in there will need to be sanitized before printing in the theme.
The suggestion to show the node as a View and then modifying the view templates sounds pretty crazy, though it'll work.

Where are WordPress default widget files or functions located?

I'm trying to slightly modify the default WordPress tag cloud widget. I don't want to create my own widget because I literally want to adjust one small thing. I've looked through my WordPress installation but can't find the PHP file that contains the basic widgets.
Even though I assume that they are defined in each theme, I still looked in the core directories but came up empty handed.
So if any of you happen to have already figured this out, please make my life easier and let me know where I can find the default widgets...most importantly the tag cloud widget.
Thanks
Those are located in the default widget class:
/wp-includes/default-widgets.php
For more detail:
http://phpdoc.wordpress.org/trunk/WordPress/Widgets/WP_Widget_Tag_Cloud.html
The widget invokes a function deeper though that generates the actual output. You'll want to take a look at the wp_tag_cloud and wp_generate_tag_cloud functions in:
/wp-includes/category-template.php
do take into account however that you'll lose your change when you upgrade wordpress (which is why I eventually did create my own shabby category-cloud widget instead of changing the default tag-cloud code).
The tag cloud widget is defined near the bottom of the default-widgets.php file in the wp-includes folder.

Resources