[google-appengine] Joomla CMS and GAE
Yes, I want to store the rule data in configuration.php and then on initialization instead of the hardcoded rules I'm testing with, the rules can be dynamically generated and registered with the wrapper. The only problem I have with that is Joomla won't save arrays of data by default in configuration.php - so it means either a plugin to save the data as an array, or limiting it to X number of rules Indeed configuration.php might be the right place for it. A custom field type could be useful, something that serializes a set rules to json. I think I even have something in place. Let me know and I'll send it over to your repo. I've got some time to work on this again, thanks for your pull requests and fixes. After a lot of thinking, I decided on a somewhat different path. Since GAE allows me to execute PHP code BEFORE the Joomla application, I'm going to replace JConfig with a new class. Instead of saving configuration.php as a PHP file with JConfig class, when executing under Google App Engine JConfig can be a virtual empty class with a large number of static variables[though I have some plans on adding extra functionality]. The configuration data can be saved to Google Datastore and serialized and saved to the memcache server. This will allow us to actually make changes to the Joomla website configuration and have those changes saved out to datastore. With that, I don't need to json encode arrays since they can be stored by serialization. That said, I'd love to add the json form field as well since I should probably create a standard configuration.php file in case someone wants to move a GAE Joomla CMS website to Google Computer Engine. I'm mainly trying to balance my tendency to add in lots and lots of options with keeping things simple so I can get to a release/usable point I mean, why spend weeks adding a bunch of options I don't need if only 2 people are using it? There doesn't seem to be a lot of interest in deploying Joomla to GAE - it's fun for me and it's a good brain teaser to force my mind into a coding gear. I completely agree here. I think more people will get involved once it's fully functional, officially mentioned on the Joomla site and maybe posted on some good blog like http://sitepoint.com Many developers probably don't consider GAE yet as PHP support in GAE is still experimental and there still seem to be many bugs around. My gut feeling is that devs will be using it for really heavy workloads since It really has a big potential as PaaS. Will see, I'm working on getting it to an install point. :-) I've been testing Joomla on Azure recently and would be extremely convinced to stick on it if not the fact MySQL is provided by a 3rd party company with scaling limitations and very harsh limits on free tier for testing (20 MB database !?), bigger options get very expensive. I'm also not really convinced by Windows environment though it's PaaS and I shouldn't care what it is running on. I've run the Joomla! CMS under both IIS and recently on a Windows server running Apache and PHP... I've always run into some odd problems here and there and I just avoid windows in general - having gone so far as to completely switching to Linux[Linux Mint Mate in fact] on all my systems to force myself to stop fiddling around with windows. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Google App Engine Module Instances - separate or not?
If an application is configured with multiple modules, for example I want to have the option to seperate out the admin part of the website from the front end and configure them as seperate modules - if both modules are used at the same time will they use two seperate instances even at low load, or is the decision to start multiple instances based on load? For example, there are a couple of front end ajax functions that, when a super admin is logged on, will poll the admin part of the website for some statistical data. When testing, the load will be low so without modules it would be a single instance. With modules is it forced to run as two instances? -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Configure static file handler/path via app.yaml or dynamically?
With the local SDK, static files have a special handler which can serve their data without requiring the instance to be executing. It strikes me that it would be useful to allow for a redirect handler as well. This would help for static files where you want to store the files in a Google Storage Bucket so they can be updated without requiring a deployment of a new version of the app code, as such I've submitted a feature request for this in 10459. https://code.google.com/p/googleappengine/issues/detail?id=10459https://code.google.com/p/googleappengine/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Loggroupby=sort=id=10459 By extension, it would also be useful to allow for a redirect handler to google storage either dynamically or only if a GS object exists in order to support caching. IE a PHP application could dynamically generate HTML for a page, then save the html to Google Storage under a pre-determined object name and in the future the redirect handler can access that instead: https://code.google.com/p/googleappengine/issues/detail?id=10460 Don't know if others would also like this, so I figured I'd post about the requests here in case there is broader support. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Re: Morphing PHP Stream Wrappers for App Engine
On Friday, January 3, 2014 6:35:40 AM UTC-5, WooDzu wrote:
Hi Gary.
I've run the */st* tests on my account and except for the one above they
all are doing well.
Reading path ggsm://log/mylog.txtbr/Warning: fopen(ggslog://mylog.txt):
failed to open stream: garyamort\github_io\stream\syslog::stream_open call
failed in
/base/data/home/apps/s~woodzu123/2.372788013017868220/gae/libraries/garyamort/github_io/stream/morpher.php
on line 162Warning: file_get_contents(ggsm://log/mylog.txt): failed to open
stream: garyamort\github_io\stream\morpher::stream_open call failed in
/base/data/home/apps/s~woodzu123/2.372788013017868220/gae/demo/streamtest.php
on line 156
I've got both the 'log' folder as well as the mylog.txt file in it. Both
created manually and assigned Owner permissions for the GAE application
in *log/mylog.txt*.
The default stream wrapper I'm using for the log directory is a syslog
wrapper - so it won't try to write to mylog.txt [I just created the file to
make sure I wasn't writing to it]. My initial implementation ran into an
issue where syslog would have problems with the newline charector, I'll
have to review the code in both places and sync them so the code to
eliminate newlines is in there.
The way it should work is it will appear in the Google Cloud console logs
for app engine. The filename becomes irrelevant - but it will show up in
the syslog messages in case it's relevant.
One suggestion I'd have is to use something more obvious for the schema
names, maybe:
gs+sm:// or gs+joomla:// for the default wrapper
gs+log:// for the log wrapper
According to RFC 1738 the following characters are allowed:
- letters a--z
- digits
- plus (+)
- period (.)
- hyphen (-)
I'm fine with changing the defaults stream type/string - I'll give yours a
shot. Note, the default stream types are completely overridable - it's all
stored in a public static array
So calling:
$mylogstreams = array('gs+syslog', 'gs+log', 'log');
garyamort\github_io\stream\syslog::types=$mylogstreams;
BEFORE calling:
garyamort\github_io\stream\syslog::registerWrapper();
will change the strings the syslog stream wrapper uses to detect on Heck,
I also set it up so you can override it by passing the strings to the method,
ie:
$mylogstreams = array('gs+syslog', 'gs+log', 'log');
garyamort\github_io\stream\syslog::registerWrapper($mylogstreams);
Does the same thing. registerWrapper is mainly just a convenience function to
avoid having to type out
stream_wrapper_register('gs+log', 'garyamort\github_io\stream\syslog');
Over and over for every one of the silly stream wrappers. So I made sure that
everything is completely overrideable/public. The method prefers to use an
array of strings given to it, if none are given it uses the public static
variable for the class that was called. And it includes a force option
defaulted to false that when set, will unregister any existing stream
wrappers[for the same strings/stream types] and replace it with the one being
registered.
How are you getting on with adding this to the cms? Let me know if I can
test anything for you.
I had to get some paying work done, I should have some time tomorro to go
through and make some updates and merge your pull requests. I need to add
in file mode checking and stream context modifications and then it should
be in good shape.
There are a number of git stream wrappers out there, and it's possible to
deploy to google app engine via git - so for people who want to
upgrade/install extensions on gae, a morphing rule that is only applied for
streams opened in write mode and then rewrites the pathname to use git
might provide most of the solution to upgrading in place...
And what are you thoughts on including media/images folders in the wrapper?
I was thinking of adding an option to the installer (the GAE one) to copy
both folders over to the Google Storage.
The images folder is used to store all dynamic data for Joomla such as
images for articles and other components, so it should be fine as is but
all of the default contents in media folder are core assets. Unfortunatelly
some 3rd party extensions by default use media to store all dynamic data in
it
such as forum attachments in Kunena, some K2 files, avatars in
CommunityBuilder and who knows what else.
One idea is to copy both images and media to the Storage, rewrite the urls
and use a post-deployment script to update/override them. Less hassle.
The other idea is to keep a list of folders which should be kept on the
Storage. Example:
/cache
/tmp
/media/kunena
/media/k2
Or even two lists eg. the default one that comes with the joomla-gae repo
and a custom one, user defined, gitignored file.
This way we can have a file for known folders used dynamically by
extensions and dev/admins would have an option to add custom folders they
need write access to.
Yes, I want to store
[google-appengine] Morphing PHP Stream Wrappers for App Engine
While working on getting Joomla to work without core file hacks on App Engine, I ran into some trouble where it attempts to build paths based on the path the index.php file is in. Specifically, it tries to send media files[images] to JPATH_BASE.'/media', cache files to JPATH_BASE.'/cache', and some log files to JPATH_BASE.'/log', Rather then running with all that code imported from google cloud storage, I instead setup a stream morpher/wrapper. By default it can self register itself to handle all streams beginning with ggsm:// and it can be assigned a set of simple pattern matching rules to access a different stream. IE for any file that begins with ggsm://log/$pathname it will instead access ggslog://$pathname For anything going to ggsm://cache/$pathname it will instead use gggs://bucketname/$pathname Where ggslog is the protocol string assigned to a simple syslog wrapper so all data sent to a log file will instead be routed to syslog and use the google logging api. By the same token, gggs is routed to my own custom copy of the google cloud storage stream handler - the only changes there being that instead of a final class, my stream class is a public class that can be extended for other functionality - and I added append mode support for opening files[which I discovered on App Engine requires using the GoogleStorageClient classes in order to retrieve the data to append - you can't open a read stream to a path if you are in the middle of opening a write stream]. I've dumped the classes into a github repo if anyone else needs them: https://github.com/garyamort/Stream-Morpher One thing I'd like to do is expand the Google Cloud Storage class to use APC caching[as long as it is available] in addition to memcached. I am thinking that for APC caching I would limit it to only 1 second - the files I am using don't generally change more quickly then once a second, and if they do it's ok when multiple instances are running for seperate instances to have stale data. Since a single user will generally be routed to the same instance, anything cached in APC for them will be available there immediately - while memcached can provide up to 15 minutes of caching as a fallback, and if those fail the slower load from GS can be done. Also it is relatively simple to support file locking and such via GS metadata. Since each request has a unique request id assigned to it, it's easy to store GS metadata with the request id and time of file lock. The lock function can limit honoring of locks to a small timeframe[say 5 seconds] and if the lock was performed more then 5 seconds ago - there are a number of special metadata update parameters that can be set so that it will only update if the current data matches the previous data. IE: lockRequestId=1,lockedAt=12/12/12 12:12:12 The second request could try to update the meta data to: lockRequestId=2, lockedAt=12/12/12 12:22/01 only if lockRequestId=1,lockedAt=12/12/12 12:12:12 So with competing requests attempting file locks, only the first one gets the lock - the second will fail and have to wait again. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Issue with Cloud Storage GCS API on local Development Server
On Saturday, December 21, 2013 12:52:13 PM UTC-5, Ken Bowen wrote: Gary, Are you using namespaces and running your code in a non-default namespace? That was my problem (see the very end of my original post.) My revised code for 11/21 runs in the default namespace -- that's why it worked. PHP doesn't support namespaces yet - so I suspect the problem has something to do with the way GS storage is emulated on the SDK and the pseodo datastore interface for PHP. As a workaround, I added a special stream to read/write from so on my dev server it can use files while on the GAE server it uses google storage. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Using Google Cloud Storage for caching and sessions under PHP
While working on getting the Joomla CMS functioning on GAE, I've been learning a few things. One item I did was setting up a GAE specific memcached driver for caching and session handling. However, after doing so and digging a bit deeper, I realized that there are 2 different memcached implementations. Method 1: Shared memcached.. You can't lock sessions when updating - and since it is shared, your cached items can be evicted from memcache due to unpredictable usage by everyone else sharing the cache[a reasonable expectation]. This makes it especially bad for session handling as you can lose a session fairly easily. Method 2: Dedicated memcached. Solves the eviction problem - but if you only need a small amount of cache space[under 50Mb] your going to have to overpay since the minimium space you can reserve is 1G - so you pay for a lot of wasted space. The gs:// stream driver for Google Cloud Storage turns out to be an excellent option - you get file like access to the cached data - so you can lock and unlock the file. You can configure buckets to expire objects. Minimum time to live is 1 day, so it doesn't help with cache management for things that should expire in, say, an hour. But what it does do is allow cache cleaning for a website that has a sudden large spike in traffic[and thus a large number of cache files are created] - and then traffic stops for a few days. If you set your lifetime to 1 day, then you know that there is some sanity checking and cleaning of temporary files that will occur regardless of if the cached item is checked. So you can eliminate the spending time on garbage collection, and only check expiration dates for items as they are retrieved to make sure they are not stale. Plus the PHP stream driver will automatically cache any file read from google cloud storage into the GAE memcached system - and you can configure the TTL for that cache. The driver will automatically check memcached before trying to read a file from GS AND whenever a file is written to GS it automatically will delete it from memcached if it has been saved there. So by using Google Storage you get the speed of Memcached AND the dependability of Google Storage. I think I've found my session handler. :-) -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Using Google Cloud Storage for caching and sessions under PHP
On Friday, December 20, 2013 12:54:06 PM UTC-5, barryhunter wrote: On 20 December 2013 17:38, Gary Mort gary...@gmail.com javascript:wrote: So by using Google Storage you get the speed of Memcached AND the dependability of Google Storage. Yes. That's good way. I was planning on using Datastore to store my session data and using shared Memcached to speed up lookups. But since Google built the functionality into the PHP stream handler, it just doesn't make a lot of sense to do so. Especially since there seem to be some problems with using the Datastore that way[the SDK emulates Google Storage using the Datastore but for some reason it is not able to retrieve the data it stores there. ] -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Cloud SQL quadruple billing on idling IP address?
I realise that considering the cost, this is a very minor nit - but the billing for idling IP addresses seems...odd. For my test google app, overnumerousness-site I was seeing some very odd usage charts. My Cloud SQL instance seemed to be constantly running, despite there not being any traffic. Checking the database usage for the past day, I saw an extremely small read/write blip occuring approximately every 15 minutes. Checking my GAE instance log files, I see that about every 15-16 minutes there is a single request for /index.php from my own ip address. Turns out there is a polling script on the page by default that runs to keep my session alive since I had a config screen open in the browser. This means for the last day[and during some other days], my app usage when idling is: 10 minutes of idling, Cloud SQL and GAE Instance turn off. 5 minutes later, the browser requests index.php. Cloud SQL and GAE turn back on. 10 minutes of idling, Cloud SQL and GAE instance turn off. 5 minutes later, the browser requests index.php. Cloud SQL and GAE turn back on. That amounts to roughly 40 minutes out of every hour where the Cloud SQL instance is active, which seems to match the jump in hours I noticed from yesterday to today because it wasn't quite a full X hours from when I was last working on it[around 9PM yesterday]. However, what is odd is that there seems to be a massive jump on the idling ip address hours... It seems that instead of measuring elapsed clock time, it measures each occurence. So over the course of an hour, there will be four 5 minute idling gaps - and for each of those occurrences it charges a full hour - so I'm paying for 4 hours of ip idling which really only took 20 minutes? It's a very small nit since it really is my own fault for not releasing the ip address when I finished working at 9pm last night[and for not closing the windows running the keep alives!] but I figured I'd mention it in case anyone else is seeing thing...it was driving me crazy trying to figure out how I was simultaneously wracking up hours of cloud sql time AND ip idling time when no one was even accessing the application. :-) -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Re: Cloud SQL quadruple billing on idling IP address?
On Friday, December 20, 2013 2:19:50 PM UTC-5, Gary Mort wrote: I realise that considering the cost, this is a very minor nit - but the billing for idling IP addresses seems...odd. For my test google app, overnumerousness-site I was seeing some very odd usage charts. My Cloud SQL instance seemed to be constantly running, despite there not being any traffic. Checking the database usage for the past day, I saw an extremely small read/write blip occuring approximately every 15 minutes. Checking my GAE instance log files, I see that about every 15-16 minutes there is a single request for /index.php from my own ip address. Turns out there is a polling script on the page by default that runs to keep my session alive since I had a config screen open in the browser. This means for the last day[and during some other days], my app usage when idling is: 10 minutes of idling, Cloud SQL and GAE Instance turn off. 5 minutes later, the browser requests index.php. Cloud SQL and GAE turn back on. 10 minutes of idling, Cloud SQL and GAE instance turn off. 5 minutes later, the browser requests index.php. Cloud SQL and GAE turn back on. That amounts to roughly 40 minutes out of every hour where the Cloud SQL instance is active, which seems to match the jump in hours I noticed from yesterday to today because it wasn't quite a full X hours from when I was last working on it[around 9PM yesterday]. However, what is odd is that there seems to be a massive jump on the idling ip address hours... It seems that instead of measuring elapsed clock time, it measures each occurence. So over the course of an hour, there will be four 5 minute idling gaps - and for each of those occurrences it charges a full hour - so I'm paying for 4 hours of ip idling which really only took 20 minutes? It's a very small nit since it really is my own fault for not releasing the ip address when I finished working at 9pm last night[and for not closing the windows running the keep alives!] but I figured I'd mention it in case anyone else is seeing thing...it was driving me crazy trying to figure out how I was simultaneously wracking up hours of cloud sql time AND ip idling time when no one was even accessing the application. :-) As a sidenote, I changed my billing plan from per use to per day since while testing I'm going to be using it erratically anyway - per day seems a better choice. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Re: Issue with Cloud Storage GCS API on local Development Server
On Tuesday, November 19, 2013 3:57:09 PM UTC-5, k...@form-runner.com wrote: I've encountered a problem using the Google Cloud Storage GCS Client API, running on the local development server. I'm trying to write the bytes from a PDF file, and then read them back. The code appears to write the (local fake)GCS file ok: (1) There appears to be an appropriate entry in the Development Console, and (2) there's a physical file in ~war/WEB-APP/appengine-generated (details below). However, when I attempt to read the bytes from the GCS file, it throws a FileNotFound exception when it attempts to get the metadata (filesize).\\ I have the same problem with 1.8.8 using PHP. I can go to http://localhost:8000 and see that there are a bunch of datastore items being created from the PHP calls to save data to a file[and I can even see that the filenames in datastore match the ones that should have been created]. However, any subsequent attempts to stat those files results in a file not found error[ie check the filesize, check to see if the file exists, etc]. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Google Cloud Storage: local SDK failures in PHP
The local SDK's implementation of Cloud Storage seems faulty.
With the local SDK, the key for the filename does not match the hash used
to test it. For example:
Trying to create a text file to cache some data. My app will create 3
files:
65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-4035f745484f79c89073a196c46b3e8a.jsonhttps://storage.cloud.google.com/overnumerousness-site-cache%2Fcache%2F_system%2F65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-4035f745484f79c89073a196c46b3e8a.json?response-content-disposition=attachment;%20filename=65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-4035f745484f79c89073a196c46b3e8a.json
65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-8fd4480eb27d93ea5a1239204577441a.jsonhttps://storage.cloud.google.com/overnumerousness-site-cache%2Fcache%2F_system%2F65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-8fd4480eb27d93ea5a1239204577441a.json?response-content-disposition=attachment;%20filename=65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-8fd4480eb27d93ea5a1239204577441a.json
65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-929adb9b368342c818ec393fb978a452.jsonhttps://storage.cloud.google.com/overnumerousness-site-cache%2Fcache%2F_system%2F65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-929adb9b368342c818ec393fb978a452.json?response-content-disposition=attachment;%20filename=65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-929adb9b368342c818ec393fb978a452.json
These are all created in the same bucket, gs://bucketname
and in the same subfolders cache/_system
So, for example, the full pathname of the first file will be:
gs://bucketname/cache/_system/
65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-4035f745484f79c89073a196c46b3e8a.jsonhttps://storage.cloud.google.com/overnumerousness-site-cache%2Fcache%2F_system%2F65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-4035f745484f79c89073a196c46b3e8a.json?response-content-disposition=attachment;%20filename=65f1b09f8d57d15f0ec5f76d57ee034a-cache-_system-4035f745484f79c89073a196c46b3e8a.json
I'm running under the Joomla CMS. Whenever a new set of data is cached, it
will call a method to generate a filename based on a hash of the key. It
also runs a check to make sure the subdirectory for the group exists.
*// returns the hashed monstrosity of a filename*
* $name = $this-_getCacheId($id, $group);*
*// Creates the fill directory name of gs://bucketname/cache/_system *
*$dir = $this-_root . '/' . $group;*
* // If the folder doesn't exist try to create it - presumably when run for
3 files sequentially would only need to be called once*
* if (!is_dir($dir))*
* {*
*// Instead, this gets called 3 times - remove the comment from the echo
clause and watch it keep running*
* // echo creating $dirbr/;*
* mkdir($dir, 700 , true, $this-dirctx);*
* }*
*// returns the full pathname for the file to store to gs. *
* return $dir . '/' . $name . '.json' ;*
By the same token, attempts to retrieve saved data from Cloud Storage
via the local SDK also fails.
I'm wondering if maybe there is a filename length limit I'm hitting on the
local SDK which does not exist for the deployed app?
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Cloud SQL bugs?
When using the Cloud Admin to set the root userid, this password is only set for root@% not root@localhost [and presumably not root@127.0.0.1] When connecting remotely by ip address, you can use the root password since the % matches. When connecting from a deployed Google App Instance, the root user cannot use the password that was set since it checks against root@localhost instead of %. Updating the password for root@localhost through the remote mysql connection allows internal access. Slightly problematic is the instance naming convention: /cloudsql/overnumerousness-site:joomla In the Joomla CMS, and many other traditional open source apps, the database connection info is generally stored as host:port:socket and a simple explode call on the string yields all 3 variables: host port socket So a simple configuration for Cloud SQL would be: ::/cloudsql/overnumerousness-site:joomla But when passed through a brain dead explode, this means the database name[the :joomla part] is lost. For Joomla, it is using regular expressions to handle ip4, ip6, and a bunch of other oddball configs. There the format would be: localhost:/cloudsql/overnumerousness-site:joomla and it would determine whether to use the second half as a port or a socket based on whether it was a number or a string - but again it is still losing te :joomla so it will fail. If it is possible to use a different seperator in the socket string, ie /cloudsql/overnumerousness-site__joomla then PHP apps using the colon as a break indicator will work with fewer changes. Since Joomla! uses lazy class loading/autoloading by default for all it's classes - and since GAE allows for a running initialization scripts before executing the traditional scripts, I found it relatively easy to fix by adding a modified mysqli database class for Joomla! and making sure the directory it is in will be checked before the Joomla! classes so it will override it. https://github.com/garyamort/joomla-gae/tree/overnumerousness So I think this issue is mostly just a minor nit, there is an easy workaround. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Best Practices for PHP
I was wondering if there are any best practice web sites on using PHP on Google App Engine. While working through installing the Joomla! CMS on GAE I've run into some weird oddities and initially have taken a rather brute force approach to work through them. Being unhappy with the brute force method[which requires modifying core files in the open source code in order to accommodate GAE] I have continued to cycle on it in the back burner and am trying an alternate approach right now. Specifically, in Joomla there are 3 main entree points to an application: http://mydomain.com/index.php http://mydomain.com/administrator/index.php http://mydomain.com/installation/index.php So far I've run into 2 issues: 1) Joomla uses XML files in order to define html form's. PHP is used to parse those files and then build the forms. GAE disables the ability to load /remote/ XML files in PHP by default. It is possible to allow this by add libxml_disable_entity_loader to the list of enabled functions and then to call libxml_disable_entity_loader(false); at some point in the code. For some reason, despite the fact that these are LOCAL xml files Jooma attempts to read, I still need to use this fix to allow Joomla to read the local files. 2) Joomla defaults to saving sessions in files, GAE defaults to saving sessions in memcache. Attempt to save session files using the default save_path does not work since the path does not exist. Making a small hack to make memcache the default does not work because Joomla checks for the existence of the Memcache extension[via extension_loaded()] which does not exist in GAE. A slightly more involved solution required me adding a new GaeMemcache class to override that check, and modifying a core class to force it to enable GaeMemcache. None of this is bad...it's just inelegant and messy. It strikes me that this was the wrong way to go about it. Because of the way GAE is configured through app.yaml to match URI patterns to individual php files - instead of changing the core code, I can instead provide a pre-loader to process the file. So my new file structure will be as follows: /gae/joomla-site.php /gae/joomla-install.php /gae/joomla-admin.php /gae/lib/gaememcache.php /gae/appl.yaml /joomla-cms : submodule git repository pointer for the Joomla-CMS repository With this layout, I can now define my 3 entree points so that instead of loading the various index.php files directly, I can proxy the call first by the /gae/joomla* php file. That gives me the ability to make any Google App Engine modifications needed[defining a special memcache handler for GAE, making my libxml_disable_entity_loader function call - etc. No core hacks needed - now I can just setup a special pre-processors to handle everything. The configuration ability of GAE is extremely fascinating.. In many ways it is overly cumbersome for simply usage due to the options available - but the options also allow for neat little workarounds[I also realized that instead of hacking the core file, I could have made a copy of the core file under my gae directory and used the upload path overrides to overwrite the core files only when uploaded/deployed to GAE] What I am somewhat curious about is if there are any best practices tutorials out there since this sort of situation seems like it should be common, and the various answers are intuitive once you start groking the GAE deployment system. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Best Practices for PHP
On Thursday, December 5, 2013 9:00:44 PM UTC-5, Brian Quinlan wrote: On 5 December 2013 17:30, Gary Mort gary...@gmail.com javascript: wrote: I was wondering if there are any best practice web sites on using PHP on Google App Engine. While working through installing the Joomla! CMS on GAE I've run into some weird oddities and initially have taken a rather brute force approach to work through them. Being unhappy with the brute force method[which requires modifying core files in the open source code in order to accommodate GAE] I have continued to cycle on it in the back burner and am trying an alternate approach right now. Specifically, in Joomla there are 3 main entree points to an application: http://mydomain.com/index.php http://mydomain.com/administrator/index.php http://mydomain.com/installation/index.php So far I've run into 2 issues: 1) Joomla uses XML files in order to define html form's. PHP is used to parse those files and then build the forms. GAE disables the ability to load /remote/ XML files in PHP by default. It is possible to allow this by add libxml_disable_entity_loader to the list of enabled functions and then to call libxml_disable_entity_loader(false); at some point in the code. For some reason, despite the fact that these are LOCAL xml files Jooma attempts to read, I still need to use this fix to allow Joomla to read the local files. 2) Joomla defaults to saving sessions in files, GAE defaults to saving sessions in memcache. Attempt to save session files using the default save_path does not work since the path does not exist. Making a small hack to make memcache the default does not work because Joomla checks for the existence of the Memcache extension[via extension_loaded()] which does not exist in GAE. I've filed a bug for this: https://code.google.com/p/googleappengine/issues/detail?id=10371 Hmm, I assumed that what happened on dev would also happen up one gae. Though personally I wasn't concerned with that one as a bug so much as the xml parsing - as there I need to be able to parse local files and the docs indicated it was only needed for processing remote files. I'm restarting my setup process in a new repo, https://github.com/garyamort/joomla-gae and things are going more smoothly this time. From what I learned on the first pass, I'm providing some logical separation between basic GAE test code and where my website code will be going - and thanks to the ability to restrict specific url paths to only logged on administrators of my Google App Engine project - I'm able to deploy code debugging code to dump the php config and such without having to do any coding of my own to secure it - GAE does it for me. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Windows Launcher for Google App Engine source code
Where is the source code for the Windows Launcher stored? I downloaded the latest PHP SDK and it includes the window launcher, but it would not work for PHP. I wanted to use the PHP runtime already installed by XAMPP and while it works fine from the command line - the windows launcher doesn't specify the PHP executable path. I found some code for it at https://code.google.com/p/google-appengine-wx-launcher/ but that code is out of date[it includes a parameter which is no longer used]... nevertheless I modified it to allow me to specify the PHP executable path in the preferences for the app and then pass that to dev_appserver.py properly and everything seems to be working fine. I submitted the patch back via an issue https://code.google.com/p/google-appengine-wx-launcher/issues/detail?id=21 which was when I noticed that this code has not been updated since 2009. I'd like to submit the patch to the correct source tree. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
