Web Caching in BlueBox

A new front-end caching feature has been introduced into Bluebox. This allows for mostly static, front-end content to be cached to speed up load time and reduce overall server load.

Caching is turned on via the following config settings:

 $system_cache_frontend_pages=0; //caches non-system/logged out pages
 $system_cache_frontend_pages_period=24; //number of hours before refreshing the cache

Setting $system_cache_frontend_pages = 1 will trigger the system to start caching pages as they're generated, while the period (in hours) will determine how long a page will be cached for before being refreshed.

Front end caching will be affected by the following

1. Caching is only utilized when there's no user session (ie. logged out)

2. "Post" request methods always ignore caching (such as sending contact forms).

3. Caching can be manually ignored by adding $global['nocache']=1 to the url string

4. Front-end template groups can be set to ignore caching by adding them to the bb_web_cache bbsetting: bbsetting_exclude_templates

5. Specific urls (that would otherwise be included in caching) can be excluded from caching by setting them in bb_web_cache bbsetting: bbsetting_exclude_urls - does partial matching

6. Any url with a "class" variable set ignores the cache

7. However, it is possible to include urls with "class" in them by setting them in bb_web_cache bbsetting: bbsetting_include_urls - does partial matching

The cache can be flushed manually by going to Publishing -> CMS -> Web Cache from the main LHS menu.

Cache can also be flushed via code by calling bb_web_cache->flush()  . An optional "pattern" parameter can be passed to only flush cache files matching the pattern. It must be a regular expression. This is useful when used in conjunction with a POST plugin function on a module that affects front-end pages (deleting the cache on changes to fresh the content immediately).

New Matcha/Captcha Module in BlueBox

BlueBox coders will be interested to note a new captcha/matcha module, which is configured as follows:

Basically, it uses JS to hook into an image to display the captcha (so it can be used for caching). it's called using bb_captcha::init()

e.g.

<img src="" id="matcha-img" />
<!--:class:bb_matcha:init:-->

it takes an optional "where" parameter to specifiy the img ID if different:

<img src="" id="matcha-custom-img" />
<!--:class:bb_matcha:init|matcha-custom-img:-->

the matcha is checked as normal via the $_SESSION['matcha'] value.

Sales Monitoring Module

BlueBox now has a Sales Monitoring Module (Sales > Sales Monitor). This module is set up by adding entries to the table which define how you want to monitor the sales activity.

You can specify the sales threshold (invoice value) that should trigger en email alert, specify who should get the emails and how often they should be alerted:

 

Once you have defined your sales monitor/s, you add them to the CronJob Module and this then triggers the Sales Monitor daily/weekly etc.

BlueBox and Stripe Payment Solutions

BlueBox Business System now has a formal plugin with Stripe (www.stripe.com)

 

Add the Stripe Account settings via Integration > Stripe. Here you need to insert your live and test keys - found in your Stripe account. You can also set it to run in Test/Live mode either via this settings panel or as a variable passed by the pay_button function.

One of the really nice features that the Stripe API allows is easy re-use of card details via secure tokens. This makes buyer's one-click purchasing is easily implemented using this new module.

The new plugin allows development of integrated payments within BlueBox using the Stripe API - by simply adding two lines of code:

$stripe=new bb_stripe();

resp($stripe->pay_button(array(

"email"=>$_SESSION[user][email],

"ref"=>$reload_order[order_number],

"name"=>"Payment for Order $reload_order[order_number]",

"amount"=>$reload_order[order_totalCUR]*100,

"success_url"=>"/?estore&global[p]=payment&global[success]=$reload_order[_apikey]",

"failure_url"=>"/?estore&global[p]=payment&global[failure]=$reload_order[_apikey]",

)));

3 New BlueBox PDA/Handheld Functions

BlueBox has had the addition of 3 new functions for handheld devices and PDA's.

These can be accessed via the Integration > PDA Functions module:

These functions are designed to run on a small-screen device with a built-in in-line 2D barcode scanner and will allow easy scanning of barcoded items for checking stock values, adjusting stock and receiving stock.

For the 'Receive Stock' Function there is a holding module that temprarily stores the scanned items until they are manually 'posted' into a live GRN document - this can be found in the top-menu of the 'PDA Functions' module:

Essentially this module provides access to the PDA URL which is /?pda - accessing this will launch the PDA functions:

 

Auto-adjusting Negative Stock upon GRN

When receiving stock via a GRN - Goods Received Note - in BlueBox ERP you have the option of auto-allocating the items to any Despatch Notes that have gone out within the past few hours where the stock was not available and therefore the items were marked as negative stock.

This effectively rectifies any stock that was shipped urgently before it could be recorded as received - and only happens when using the ePOS (Point of Sale) module which allows this to happen.

In order to enable this setting set the bbsetting as follows:

bb_procurement_goods_received_notes > bbsetting_grn_auto_adjust_negative_stock_within_x_hours

Set it to the number of hours prior to each GRN that you want to check for FNS Despatch Notes.
 - ie 24 would check for any DSP's that were issued within the past 24 hours whenever a GRN is captured.

Forced Non-stock (or Negative Stock) is recorded and viewed in the Forced Non-Stock Report - this report has an indicator at the top to show if the bbsetting is activated for the system or not.

When each item is auto-corrected it's value/qty in this report is reduced to zero and a link is provided to view the source GRN that performed the auto-correction. Note: these lines still remain in the FNS report so that audit trails can be done reflecting that an item was initially maked as FNS and later auto corrected.

Stopping Unwanted Page Requests

Sometimes our systems get bombarded with regular illegal page requests (probably a spider with terrible coding). In these instances it is preferable to be able to block this traffic before all the page resources are loaded.

For this purpose our Errors Module has been expanded to include an option to 'intercept and block at header' option - this is configured as follows:

The 'error message' field (normally used for part of the human-readable error message generated by system errors) is now used to specify the query_string being passed in the URL that is being used.

The 'intercept and block' setting must be set to yes: