joomla / joomla-framework

[READ-ONLY] This repo is no longer in active development. Please see https://github.com/joomla-framework for the individual Framework packages.
http://framework.joomla.org
GNU General Public License v2.0
189 stars 140 forks source link

Adds Google App Engine specific memcache drivers for Cache and Storage #312

Closed ghost closed 10 years ago

ghost commented 10 years ago

Adds Google App Engine specific modifications for Cache and Session Storage.

While the vanilla memcached engines should work for an app running in a live GAE instance, they won't work when running locally and they include calls to methods which GAE does not implement.

Specifically: Replace any checks for the Memcached extension with checks of $_SERVER variables to see if we are running under GAE[local SDK does not use the extension].

Removes calls to addServer[GAE App Engine does not use this feature] or attempts at trying to set a memcached server.

pgasiorowski commented 10 years ago

+1 @mbabker Is there any chance for the cms to pick this up for current master branch? It'd be a shame if LTS 3.5 missed google app engine integrations.

mbabker commented 10 years ago

Don't see why this and the database driver couldn't be backported into the CMS.

ghost commented 10 years ago

See the overnumerous branch of my joomla-gae repo: https://github.com/garyamort/joomla-gae/tree/overnumerousness

Specifically, the files in the libraries folder would need to be merged into the libraries/cms or libraries/joomla folder https://github.com/garyamort/joomla-gae/tree/overnumerousness/gae/libraries

The main sticking point is the JCache, JSession, and JDatabase all look only under the directory of the file the class is defined in when loading drivers - since I wanted my drivers seperated for clarity, it meant I had to also make copies of those 3 classes and modify them to check 2 directories instead of 1 in order to work. So if my drivers from there get merged into the libraries/joomla subfolder for the CMS they should work. I can submit all of those once I finish testing[and changing things...originally I called my db driver gmysqli but changed it to gcloudsqli as it seems more clear].

piotr-cz commented 10 years ago

@garyamort I've found this problem, too with JCache and JSession. Did you have idea about implementing a manual driver registration mechanism?

In CMS I like how I can add new JHtml helpers using the JHtml::register method. Anyway, in the CMS you may specify the destination folder for drivers, to be /joomla/cache/storage/ in the extension manifest.

ghost commented 10 years ago

Updated driver:

Fixed checks for the appropriate drivers.

If it passes style checkes, if you can give it a test WooDzu that would be great!

ghost commented 10 years ago

@piotr-cz the CMS is a confusing case. For JCache, JSession, and JDatabase it is inconsistent in when it calls the root class function to get a list of available drivers. IE for JDatabase it only calls for the list if you are making changes to the Joomla configuration - otherwise all it cares about is that a class exists called 'JDatabaseDriver'.$dbdriver where $dbdriver is the string stored in configuration.php specifying the driver.

For JCache and JSession, there are some other times it calls those functions and it's a real pain. Thus my answer is to create a new copy of JCache and JSession which can check multiple directories[original and new] to build the list. In GAE I have a lot of freedom in running some custom PHP code before starting Joomla so I can fiddle the classes - in a non-gae environment I would not that if the file defines.php exists in the same directory with index.php that file will be loaded BEFORE Joomla is initialized, so you can place code there to fiddle around with classes.

I use a system plugin in GAE which modifies the Joomla configuration form to change the list of options available.

I try to never, ever, ever modify the code that comes from Joomla! because if I make changes it makes it harder to use Git to install/upgrade to the latest code. Plus I have some dumb file checks I run every now and then to generate MD5 signatures of all the "core" files installed on my system and compare against the repository code to ensure nothing is changed.

ghost commented 10 years ago

@piotr-cz

Oh I should mention, the reason I'm not concerned about fixing it in the CMS for Cache and Session handling is because cache and session handling have changed quite a bit in the platform and those changes have not made it into the CMS yet....when they do make it in the lookup process for enabled engines changes anyway.

ghost commented 10 years ago

Close pending other changes which need to be incorporated