NYCPHP Meetup

[Gary Mort]

I wanted to gauge interest here.  I'm setting up my own personal 
websites and I find:
Joomla! is 60% of what I want
20% of what I want can be handled with custom components, templates, 
modules, and plugins
5% of what I want is either in the next platform or cms release
10% of what I want can be handled with autoloaders and overrides
5% of what I want requires hacking core code

Now, if I was my client, I'd tell myself to focus on what I /need/ not 
what I want and try to eliminate any core hacks and most of the overrides..

But I'm not a client, I'm me.  And everytime I start setting this up I 
get frustrated because it doesn't meet my artistic vision - and I'm not 
willing to compromise my vision[wow, I sound like a silly *artiste* 
don't I?]

So the solution is simple, fork Joomla!
Not in a competitive way, but in the way I've seen done on countless 
client projects where they have some custom code they use in house and 
no one else ever see's the code.

My plan is to create a fork of the Joomla! repository.  Then in that 
fork create 2 new branches, one for dev/hacks and one for 
releases...ideally 80% of released code could be pulled right back into 
Joomla!...and if it's pulled properly, when I update my fork from their 
it will integrate seamlessly and override my own code.

My question is, how many people are truly interested in playing around 
with it?  Not just a cursory glance, but truly looking it over and 
testing it out?  Because my early code will often have stuff I don't 
want publicly available, I'll be placing it all in a private github 
repository...and I'm not willing to pay for that so it means charging a 
nominal annual fee for repository access[say 24$/year to make sure 
people are serious and make sure I don't end up losing money to 
Github].  Almost everything there will....eventually make it out into 
the public either as an installable Joomla! extension, or pull requests 
back to the source.

As a quick summary of what I "want":
Multi-site single installation codebase: All Joomla needs is 2 changes 
to support multiple domains from the same codebase.  It needs a 
hook/plugin for the query builder so a domain filter can be added to 
when using specific tables[for example, where DOMAIN='mydomain.com'] and 
a pre-system setup call to set the domain.  That is it.  Everything else 
is in there, plugins for editors can add the domain selector.  Plugins 
for forms can filter out domain specific info, etc.

Unified Content: Taking a leaf from Drupal, instead of storing raw 
content in the content table, I'd much rather store content that has 
already been formatted for display and is searchable.  All it requires 
is adding an content type mapping to map content to different components 
for editing and in one swell fwoop you get rid of 90% of the SEF 
headaches...SEF now can almost /always/ use content sef mapping.  Other 
components augment content rather then display different content.  It 
also solves 75% of searching issues as all searching can be done on the 
content itself, not different searches.

Null Storage engine for Caching:  Over and over in the codebase there 
are all these components that store objects they retrieve so they don't 
retrieve them over and over.  But we already have a class that does 
this, Cache....the only problem is that cache is for storing data TO 
somewhere.  But in this case, we only want to store data in memory.  So 
use cache.

Caching priorities:  TTL SUCKS as a caching strategy.  Basically it says 
'save this for 15 minutes, then throw it away'.   As long as I am 
caching data, I want it to be intelligent!

A typical Joomla! Caching snippet:
   $cache = JFactory::getCache("com_mycomponent", "");
   $cacheKey = $this->getId();
   $item = $cache->get($cacheKey);
    if (empty($item)) {
    // do some stuff to get the item
    $cache->store($item);
   }
   // do something with the item

How...wasteful.  Why not:
   $cache = JFactory::getCache("com_mycomponent", "");
   $cacheKey = $this->getId();
    $importance = JCache::HIGH;
    $softLimit = '360';
    $hardLimit = '3600'
   $item = $cache->get($cacheKey, $importance, $softLimit, $hardLimit);
   $p = JProfiler::getInstance(cacheKey);
$p->mark('Start');
    if (empty($item)) {
    // do some stuff to get the item
$p->mark('Stop');
    $retrievalTime = $p->buffer;
    $cache->store($item, $importance, $softLimit, $hardLimit, 
$retrievalTime);
   }
   // do something with the item

Wow...NOW we have some metrics.  We know how LONG an item took to 
retrieve.  All things being equal, objects with the same importance 
should be expired based on the time they take to generate, not FIFO.  So 
if you have 2 objects and one takes a millisecond to generate, and the 
other takes 1 minute[think an internal db call vs an external REST call 
to grab a chart image from Google] - isn't it obvious which one to throw 
away first?

And by using soft and hard limits, instead of simple TTL, we can keep 
'stale' data until it gets updated.  A stock price from Google is just 
as valid an hour from now as 10 minutes from now - but maybe we want to 
retrieve it every 10 minutes if possible, but will settle for older data 
in some circumstances.

Lastly, passing the importance flag to the retrieval as well as the 
storage allows different items to 'upgrade' cached data.  Maybe it 
wasn't important to one section of code, but another call on a different 
page really needs the cached data if at all possible because otherwise 
it bogs down.

Speaking of Cache...  PHPSerialize is wonderful...if everything is 
running PHP.  But what if you have a caching proxy sitting up front?  
For a stupid logon module, you destroy caching for logged in users since 
the upper right hand corner of the screen changes from: Login... to: 
Hello Gary, you have no new messages

A caching server could use esi:include 
url="http://mydomain.com/userwelcome" and cache everything else but grab 
that info from the server.  Even better though, since you have a 
sessionid cookie, instead it could be: 
src="memcache:get(sessionid->userwelcome)" and if the data is stored in 
memcache with a sessionid in json format, poof!  It appears.  No server 
hit needed.

And why should we lose the ability to count hits just for the sake of 
caching a page?  Almost every caching system today allows for that!
esi:include src="memcache:incr(<articleId>Hits)"

Sure you occasionally have to sync that data back to the database....but 
its much more fun!

Just figured I'd throw it out there.  If there is stuff others "want" 
that would make them willing to pay $24/year for feel free to throw it 
on the pile and if it's amusing enough it will probably get in there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/joomla/attachments/20120413/4358bfc9/attachment.html>