Welcome

LiveWhale is a framework atop which we’ve built a CMS designed for higher education. Besides being friendly, easy-to-use, and extremely powerful, it’s also flexible and customizable. (Yeah, that’s how we roll.)

What Happens Here?

If you’d like to make customizations or want to integrate other developers’ work into your LiveWhale, you’re in the right spot — this is what our developer website is all about.

giving you a place to give us great new features you want to see in the software through the software roadmap;
read through the documentation so that you can create your own custom modules or change the way LiveWhale works for you;
contribute modules and content to this website, for the benefit of the entire community;
keep up to date on the technologies we employ; and,
check out the garden for LiveWhale modules you can use for yourself.

About This Website

This site is a responsive design atop LiveWhale (of course), utilizes jQuery, Underscore and Backbone for the Github integration and includes code highlighting and table extras to give you the tools to explain what you need to the LiveWhale developer community. (Of course it does.)

Tidbits

Data Module Authorization
If you’re building a data module, admins editing users will automatically see it as a module that can be authorized for each user. That’s fantasically simple, but if you know that all users should be able to use this module (like Images for instance) then you can do that too:
```
          'is_always_authorized' => TRUE
        
```
Want to See PHP Errors?
As a LiveWhale admin in LiveWhale 1.4.4 and later, you can visit your settings page to find checkboxes to turn on Errors, as well as disable page caching, resource minimization and widget caching. All these settings apply to your browser alone (it’s a cookie) so you have no need to worry about other users.

If you’re still on LiveWhale 1.4.3 then there’s still an option for you. When logged in, load the url:
```
          /livewhale/?livewhale=error_mode
        
```
This url toggles PHP errors on and off for you alone by cookie, so they will stay on until you turn them off by reloading the url.
LiveWhale System Status
Wondering how the database is doing, how many cached widgets there are, or want to see the error log? Simple, goto:
```
          /livewhale/?lw_debug=1
        
```

Naming Modules

When naming modules, the title given is merely for display purposes. However, the filename, the key in the appropriate module array and the class name should all match to work correctly. Example:

          // in public.application.public_notifier.php

$_LW->REGISTERED_APPS['public_notifier']=array(
 'title'=>'Public Submission Notifier',
 ...
 'handlers' => array('onAfterPublicSubmission')
);

class LiveWhaleApplicationPublicNotifier {
 ...
 public function onAfterPublicSubmission () {
  ...
 }
 ...
}

Nesting Widgets

Ever wondered if you could nest widgets inside of widgets inside of widgets? The answer is YES. But hey, be reasonable. LiveWhale limits you to four levels deep to keep processing spritely. (That was also the limit in Inception too after all.)
Module Scopes
LiveWhale has two primary scopes, public and private. Modules that need to interact with the LiveWhale backend to change the editing of dynamic content, that is the private scope. Modules that interact with the front-end website must have a public scope.

You set the scope through the filename of the module code. For example:
```
          private.application.app_name.php
public.application.app_name.php
        
```
If you need to interact with both the front-end and the back-end, then your overall application will need both files. By the way, this is in the name of security.
How to Load Module Changes
While doing heavy module development in LiveWhale 1.4.3 and earlier, sometimes the APC cache can get in the way. To make sure that you’re seeing the freshest version of your code, you may want to refresh your environment:
```
          // to refresh backend modules
/livewhale/backend.php?livewhale=refresh_env

// to refresh frontend modules
/livewhale/nocache.php?livewhale=refresh_env
        
```
MySQL Tuner

Need help tuning your MySQL? Here’s a great resource that is incredibly useful and open source to boot. Give it a try!

MySQLTuner-perl

Data Module Authorization

If you’re building a data module, admins editing users will automatically see it as a module that can be authorized for each user. That’s fantasically simple, but if you know that all users should be able to use this module (like Images for instance) then you can do that too:

            'is_always_authorized' => TRUE