How to avoid two frameworks conflicting due to redeclared function? - php

The Problem
I'm working on a site which utilises two PHP frameworks running in parallel, Wordpress and CakePHP. Both of them contain a core function called __().
I know I can modify the core files of either framework to check if the function is declared and then not declare it:
if (!function_exists('__')) {
function __() {
// ...
}
}
However, the problem is that both frameworks need to be automatically updated from time to time, and when this happens, the core files get rewritten and the function comes back, causing fatal errors.
Wordpress is out of our control. Editors using the CMS want to be able to update the framework and plugins automatically from the Wordpress admin panel. This means I cannot really modify the Wordpress core to solve the problem, as they will just overwrite my changes every time they update.
CakePHP is updated by the developers, via Composer. Of course one basic solution would be to ensure that all developers know that when performing a Composer update, the core file declaring the function needs to be modified to fix the fatal error. This is still a pretty bad solution.
The Question
So although I am 99% sure there is no permanent solution to this, I'm wondering if any PHP gurus can think of a really clever, albeit slightly unconventional/messy, way of solving this with some code in the custom application within CakePHP. If there is something that can be done which I don't know about in PHP.
How the Application Works
The basic marketing pages of the site are pure Wordpress. CakePHP does not load on those pages.
On some sections of the site which require more complex functionality, CakePHP is loaded first. Before the page is rendered, CakePHP loads the Wordpress framework, then renders the page through Wordpress. These are the pages where both frameworks collide on the same function being declared twice.
My Thinking
When CakePHP is bootstrapped on a page, let it run up until the view is due to be rendered. At this point, only CakePHP has declared the function.
Check if the function exists before Wordpress gets loaded.
Somehow prevent Wordpress from redeclaring the function, ahead of time. We write this in our application code, which is fully controlled by the developers and committed to our Git repo.
I feel ridiculous posting this question, as I'm sure this is impossible, but if there is a really clever way of solving this, it would be so useful.

As ceejayoz said, fork CakePHP, and maintain your project on that fork.
Make a commit that will serve your project and that you can submit to the Cake team. As you suggest, make __ declaration conditional on it not already existing, declare it #deprecated in its phpdoc, and make a namespaced version that you'll convert everything to. Send that as a PR to Cake.
When you need to update your fork, merge the upstream branch into yours. You much watch the incoming Cake changes for use of the __ function and change them accordingly. Git will not catch these.

Related

How to call laravel function in Wordpress themes

I am currently developing a laravel app which I only managed the blog section with Wordpress. Everything works fine. Is it possible to call laravel function in my Wordpress function.php? If yes, how can I achieve that?
It will depend on what function you want to call. Some things can be used independent of the framework simply by including the packages, for example Laravel Collections. However if you need more in depth integration you should take a look at the following files.
public/index.php
bootstrap/app.php
bootstrap/autoload.php
It is in these files that the frameworks gets loaded. Meaning that it does all the prerequisites before your application code can run. If you wanted to use Laravel within WordPress you would need to mimic the logic from these files in WordPress. I have never done this before though, so I don't know if you will encounter any namespacing issues or anything else. You might also be concerned about the performance implications of loading WordPress and Laravel on every request. Good luck!

How can I reuse some laravel code?

I am developing web application using the laravel. I would like to 'package' some of the functions, which is re-usable. For example, I got a UserController, with database setup, and view, etc. The UserController is expected to re-use in most of the web development in the future, but some UserController may have different behavior, for example, some application's user may have a field rewardPoint, some may not. But they all have some similar behaviors, for example: register, login, forgetPassword, etc. So, can I package out a common UserController with all the basic database setup into one file or script to reduce the development work load? Thanks.
You've hit the nail on the head already - since your requirements are likely to change between projects you will struggle to create a single solution that works everywhere. You have a few options, including:
Copy the useful classes from your last project and update them to fit.
Create a package or bundle of base classes that include common and reusable code, then extend these into your project and modify the extensions as needed.
Attempt to create a "one solution for all" that you can drop in to all of your projects.
I would steer away from 3; it's likely to add the most bloat for the least gain. 1 is useful whilst you get used to the framework, especially if you tend not to revisit old projects; over time you will refine your code and develop patterns of work. Eventually you will probably end up doing 2; you can store these in git, use bundles or composer packages, and you can continue to improve them over time.

How to go about allowing plugins for a custom framework?

First off, this isn't really a programming question but more of a programming concept question. Basically, I've built a bespoke PHP framework to speed up deployment on my end and I want some kind of plugin system in place that will allow me to add specific features to the base of the framework (like the SQL class or maybe a Twitter package) that will allow me to throw them into a folder and not have to actually edit the base for every new project.
Any ideas of the best way of going about this?
Here is a nicely written post by #ircmaxell on how to do that and what are the options:
Handling Plugins In PHP
Also check out:
Best way to allow plugins for a PHP application
what im doing in my cms:
for each plugin i make a folder latin-named of this plugin's name.
i create a /translations folder in there too. Check here.
have a single php file that has 2 basic functions, the plugin_install and plugin_uninstall (you know, things to happen on install/unistall like tables creation/drop)
create a special page of your system that reads these plugins, installed and not and give an on/off switch so users can install/unistall them.
load these single files mentioned above by a single call to include_once on top of your index page (or administration page) so to include whatever functionality they offer.
enabled plugins will be loaded (include_once) from your main page, and also their functionality, so each plugin can call each other's as well.

Cleanup Codeigniter Applications Folder

I'm interested in cleaning up my codeigniter applications folder (just to clean up the clutter). I've seen a few applications that only include the important folder (ex. controllers, models, views, config) and do away with alot of the other stuff (like logs, hooks etc.)
Does someone know which folders can be deleted and which are required?
Thanks
Consider that this "clean up" won't bring you this great advantages, apart from your personal feelings. Since Codeigniter tries to look into application folders which are named like the system ones (libraries, core..) before going to search for those folders inside the "system", I don't think it will be painless to remove them; you might try, though, and just keep those which, very likely, contain somethin: config,controllers,errors,models,views.
Another thing you could do, and which will free more "space" (are you worried about file count?), is deleting unused/unwanted helpers and libraries (from the system folder); the ones you are damn sure you don't use and never will in the future (like the javascript library, for ex, plainly useless, or the smiley helper...You got the point).
All in all, apart from the feeling of "having cleaned up your workspace", I don't really see what benefit this will bring you. But, if you really, really feel so strongly inclined to, make a back-up copy and start deleting, you can always put them back if CI yells at you.
Each file and folder in the CodeIgniter Application folder is an extension of the whole CodeIgniter framework in one form or another, and should not be tampered with. CodeIgniter is a light, fast framework, and should not need any other "modifications". If you'd like to play around with CodeIgniter though to try out any "improvements"; I'd check out their page on GitHub, view some commits that may be related to your question, and play around with it yourself on your own machine.
The framework is setup so you can develop your applications and update to new versions of code igniter without breaking said applications. You don't want to start messing with the actual framework that's just asking for random errors.
if you are trying to make it as lite as possible just auto load the libraries and helpers that you require directly into the controller where they are needed.
-L

Suggest me, is it a good idea to make changes in default Joomla code structure?

Suggest me, is it a good idea to make changes in default Joomla code structure?
I need to keep an insert query after every insert/update/delete operation in Joomla administrator code. so that i can track the change i have made.
Is it good idea to make the changes every where in the default code in Joomla default structure?
Generically speaking (that is, without knowledge of Joomla internals):
If this is your one and only project and you just build upon an existing codebase, go forth and modify it. It helps to keep track on what you did where, if you want to port Joomla updates later to your codebase, but sooner or later you should make a cut.
If, however, you use Joomla for more than one project and/or want to keep in track with Joomla's future development, changing core files can (and presumably will) become a maintenence nightmare. The only way to keep this in usable dimensions is to restrict touching core files to a minimum and well-defined set of places.
I assume, you want to go with the second option. In this case, let me give you some advice on what worked at our company:
We mangled with WordPress. What helped us much, was to store WP in one folder and a version of files we touched in a different folder (in our VCS). This way, we always knew exactly, what file from the WP core we touched. Making a productive environment was 1. exporting the WP files and 2. exporting the shadow copy and move it over the WP core files.
Writing extensions/plugins: Almost any larger software has a way to extend it. Learn the plugin/hook/extension/addon mechanism of Joomla and try to do as much of your changing as possible with that.
If it's database related: Maybe it's enough to change only one file of Joomla: /libraries/joomla/database/database.php. Even better, it might be possible to extend this class (or JDatabaseMySQL, that is) and somewhere in the configuration tell Joomla to use this class.

Categories