Things​ ​that​ ​will​ ​be​ ​included Understand​ ​dev/uat/live​ ​environments Dependencies​ ​for​ ​modules​ ​clearly​ ​displayed Multiple​ ​authentication​ ​systems Simultaneous​ ​authentication​ ​systems Multiple​ ​sites/domains i18n​ ​and​ ​L10n Subfolder​ ​installation Single​ ​database;​ ​multiple​ ​installations Template​ ​language​ ​abstraction Database​ ​abstraction Draft​ ​content;​ ​Workflow;​ ​Archiving Design​ ​by​ ​contract​ ​and​ ​unit​ ​testing Automatic​ ​code​ ​upgrading Multiple​ ​themes/skins/layouts Dynamic​ ​Menu​ ​generation Import​ ​functionality Thin​ ​bootstrap​ ​for​ ​AJAX​ ​functionality Live​ ​preview​ ​of​ ​content​ ​changes Extensive​ ​Permissions Automatically​ ​triggered​ ​class​ ​intelligence Integration​ ​with​ ​Zend​ ​Tool​ ​for​ ​automatic​ ​code​ ​creation Things​ ​which​ ​would​ ​be​ ​nice​ ​to​ ​have Extensive​ ​and​ ​automatic​ ​debugging In-line​ ​editing​ ​of​ ​page​ ​elements Comments​ ​and​ ​notes Things​ ​to​ ​be​ ​discussed single​ ​node​ ​or​ ​multiple​ ​models single​ ​node multiple​ ​models would​ ​blanketCMS​ ​come​ ​packaged​ ​with​ ​modules​ ​like​ ​news/blog/products​ ​or​ ​would​ ​these be​ ​free​ ​form​ ​created​ ​by​ ​vendors packaged store​ ​model​ ​definitions​ ​in​ ​the​ ​db​ ​or​ ​on​ ​the​ ​fs fs should​ ​the​ ​library​ ​files​ ​be​ ​in​ ​a​ ​central​ ​location​ ​or​ ​be​ ​stored​ ​in​ ​each​ ​client​ ​directory central each​ ​directory

    Things​ ​that​ ​will​ ​be​ ​included  Understand​ ​dev/uat/live​ ​environments 

Different​ ​companies​ ​have​ ​different​ ​setups​ ​for​ ​their​ ​dev/uat(staging)/live​ ​environments.  blanketCMS​ ​should​ ​have​ ​an​ ​understanding​ ​of​ ​this​ ​and​ ​be​ ​able​ ​to​ ​load​ ​different​ ​configuration  options​ ​automagically.    The​ ​following​ ​differentiating​ ​options​ ​should​ ​be​ ​considered:  ● IP​ ​address​ ​range  ● domain​ ​name  ● server​ ​name  ● hard​ ​coded​ ​switch  ● environment​ ​variable    blanket​ ​should​ ​be​ ​able​ ​to​ ​use​ ​one​ ​or​ ​many​ ​conditions​ ​to​ ​determine​ ​the​ ​site’s​ ​status. 

Dependencies​ ​for​ ​modules​ ​clearly​ ​displayed 

Dependencies​ ​could​ ​be​ ​either​ ​other​ ​blanketCMS​ ​modules,​ ​or​ ​php​ ​modules/settings.​ ​When​ ​a  module​ ​requires​ ​something​ ​that​ ​is​ ​not​ ​included​ ​in​ ​the​ ​base​ ​php​ ​installation,​ ​it​ ​should​ ​be​ ​made  evident​ ​before​ ​the​ ​module​ ​can​ ​be​ ​installed.​ ​Dependencies​ ​may​ ​either​ ​limit​ ​installation​ ​or  simply​ ​limit​ ​functionality.​ ​For​ ​inter-module​ ​dependencies,​ ​these​ ​should​ ​be​ ​installed  simultaneously​ ​if​ ​possible. 

Multiple​ ​authentication​ ​systems 

blanket​ ​should​ ​not​ ​assume​ ​that​ ​all​ ​people​ ​will​ ​want​ ​to​ ​register/authenticate​ ​using​ ​the​ ​same  style​ ​of​ ​credentials.​ ​Some​ ​systems​ ​will​ ​want​ ​to​ ​use​ ​username/password,​ ​others  email/password,​ ​still​ ​some​ ​others​ ​may​ ​use​ ​external​ ​systems​ ​such​ ​as​ ​OpenID,​ ​Facebook  Connect,​ ​Google​ ​Accounts,​ ​Live​ ​Passport​ ​or​ ​a​ ​custom​ ​login​ ​solution.​ ​Therefor​ ​the  authentication​ ​layer​ ​should​ ​take​ ​this​ ​into​ ​account​ ​and​ ​offer​ ​one​ ​or​ ​many​ ​layers​ ​for​ ​users​ ​to  authenticate​ ​against. 

Simultaneous​ ​authentication​ ​systems 

Whilst​ ​a​ ​user​ ​may​ ​log​ ​into​ ​a​ ​site​ ​with​ ​one​ ​set​ ​of​ ​credentials,​ ​they​ ​should​ ​be​ ​able​ ​to​ ​associate 

other​ ​accounts​ ​with​ ​their​ ​user.​ ​This​ ​could​ ​be​ ​a​ ​custom​ ​authentication​ ​system​ ​or​ ​a​ ​default​ ​3rd  party​ ​system​ ​such​ ​as​ ​Facebook,​ ​Twitter,​ ​Google​ ​Accounts,​ ​Live​ ​Passport,​ ​Gravater​ ​etc. 

Multiple​ ​sites/domains 

Should​ ​be​ ​able​ ​to​ ​run​ ​different​ ​sites​ ​from​ ​different​ ​domains​ ​or​ ​subfolders,​ ​configurable​ ​either  through​ ​the​ ​web​ ​interface​ ​or​ ​through​ ​config​ ​files. 

i18n​ ​and​ ​L10n 

blanket​ ​should​ ​support​ ​i18n​ ​and​ ​L10n​ ​out​ ​of​ ​the​ ​box.​ ​All​ ​currency/date/time​ ​settings​ ​should  respect​ ​L10n​ ​settings,​ ​and​ ​all​ ​system​ ​text​ ​should​ ​run​ ​through​ ​an​ ​i18n​ ​layer.    Currency​ ​settings​ ​should​ ​try​ ​to​ ​determine​ ​the​ ​best​ ​currency​ ​for​ ​the​ ​user​ ​based​ ​on​ ​their​ ​Locale  settings,​ ​and​ ​the​ ​option​ ​for​ ​manual​ ​update​ ​or​ ​live​ ​currency​ ​feeds​ ​should​ ​be​ ​present.    In​ ​addition​ ​to​ ​this,​ ​the​ ​CMS​ ​should​ ​allow​ ​for​ ​the​ ​entering​ ​of​ ​text​ ​in​ ​multiple​ ​languages,​ ​and  for​ ​translations​ ​of​ ​admin​ ​entered​ ​text.​ ​It​ ​should​ ​also​ ​allow​ ​association​ ​of​ ​content​ ​in​ ​various  languages​ ​to​ ​be​ ​translations​ ​of​ ​each​ ​other.    Ultimately,​ ​blanket​ ​should​ ​be​ ​able​ ​to​ ​configure​ ​mixed​ ​environments​ ​across​ ​domains​ ​and  subfolders​ ​for​ ​i18n​ ​and​ ​subsites.    ie.  site.com​ ​-​ ​english​ ​version​ ​of​ ​site  de.site.com​ ​-​ ​german​ ​version​ ​of​ ​site  site.com/de​ ​-​ ​german​ ​version​ ​of​ ​site  site.com/subsite​ ​-​ ​subsite  subsite.site.com​ ​-​ ​subsite  subsite.site.com/de​ ​-​ ​german​ ​version​ ​of​ ​subsite 

Subfolder​ ​installation 

Should​ ​not​ ​assume​ ​it​ ​will​ ​always​ ​run​ ​from​ ​root​ ​level.​ ​Might​ ​run​ ​from​ ​/site​ ​subfolder. 

Single​ ​database;​ ​multiple​ ​installations 

Take​ ​advantage​ ​of​ ​table​ ​prefixes​ ​and​ ​rewriting​ ​table​ ​names​ ​for​ ​the​ ​ability​ ​to​ ​run​ ​multiple  sites​ ​from​ ​one​ ​database.​ ​Table​ ​prefixes​ ​also​ ​mitigates​ ​table​ ​name​ ​clashes​ ​with​ ​3rd​ ​party  software​ ​and​ ​SQL​ ​reserved​ ​word​ ​clashes. 

Template​ ​language​ ​abstraction 

Template​ ​layer​ ​should​ ​be​ ​abstracted​ ​as​ ​template​ ​designers​ ​might​ ​have​ ​a​ ​preference​ ​for  Zend_Layout,​ ​Smarty,​ ​or​ ​some​ ​other​ ​language.​ ​Different​ ​deployments​ ​might​ ​require 

integration​ ​with​ ​Flash,​ ​Android​ ​or​ ​iDevice​ ​frontends.​ ​This​ ​flexibility​ ​is​ ​a​ ​must. 

Database​ ​abstraction 

Should​ ​be​ ​looking​ ​to​ ​target​ ​at​ ​the​ ​bare​ ​minimum,​ ​MySQL,​ ​MSSQL,​ ​SQLite​ ​and​ ​possibly  PostgreSQL. 

Draft​ ​content;​ ​Workflow;​ ​Archiving 

Content​ ​should​ ​be​ ​able​ ​to​ ​be​ ​saved​ ​in​ ​a​ ​temporary​ ​status​ ​before​ ​being​ ​published.​ ​This​ ​applies  to​ ​not​ ​only​ ​only​ ​to​ ​new​ ​content​ ​but​ ​also​ ​editing​ ​existing​ ​content.    Full​ ​workflow​ ​path’s​ ​should​ ​be​ ​configurable,​ ​with​ ​roles​ ​for​ ​editors​ ​and​ ​approvers.​ ​Workflow  can​ ​be​ ​tiered​ ​as​ ​well.    Content​ ​should​ ​be​ ​archived​ ​and​ ​a​ ​trash​ ​bin​ ​should​ ​be​ ​implemented​ ​for​ ​undo​ ​of​ ​deletes. 

Design​ ​by​ ​contract​ ​and​ ​unit​ ​testing 

Code​ ​should​ ​be​ ​properly​ ​designed​ ​and​ ​implemented​ ​using​ ​Design​ ​by​ ​Contract​ ​principles​ ​and  all​ ​objects​ ​should​ ​have​ ​proper​ ​unit​ ​tests​ ​written​ ​for​ ​them.​ ​This​ ​will​ ​ensure​ ​system​ ​stability  and​ ​help​ ​with​ ​automating​ ​API​ ​documentation. 

Automatic​ ​code​ ​upgrading 

As​ ​new​ ​releases​ ​of​ ​blanketCMS​ ​are​ ​pushed​ ​out,​ ​websites​ ​should​ ​check​ ​the​ ​central​ ​or​ ​mirror  servers​ ​for​ ​changes.​ ​When​ ​changes​ ​are​ ​detected,​ ​they​ ​should​ ​be​ ​offered​ ​to​ ​be​ ​downloaded.  This​ ​should​ ​be​ ​configurable​ ​for​ ​each​ ​environment​ ​type;​ ​sysadmins​ ​might​ ​not​ ​want​ ​updates​ ​to  be​ ​automatically​ ​applied​ ​to​ ​live​ ​sites.​ ​Updates​ ​should​ ​also​ ​be​ ​able​ ​to​ ​be​ ​pulled​ ​from​ ​one  environment​ ​to​ ​another;​ ​this​ ​allows​ ​testing​ ​to​ ​be​ ​finalised​ ​and​ ​then​ ​pulled​ ​and​ ​applied​ ​to​ ​the  live​ ​site. 

Multiple​ ​themes/skins/layouts 

On​ ​a​ ​per​ ​site/role/locale/content​ ​basis,​ ​different​ ​themes/skins​ ​should​ ​be​ ​able​ ​to​ ​be​ ​selected,  and​ ​from​ ​these​ ​themes/skins,​ ​various​ ​layouts​ ​could​ ​be​ ​available.​ ​This​ ​would​ ​allow​ ​for​ ​things  like​ ​various​ ​column​ ​numbers,​ ​widget​ ​locations,​ ​and​ ​designated​ ​“home”​ ​pages​ ​that​ ​have  fundamentally​ ​different​ ​layouts​ ​to​ ​content​ ​pages.​ ​Allowing​ ​these​ ​to​ ​be​ ​selected​ ​from​ ​the​ ​web  admin​ ​is​ ​an​ ​absolute​ ​must. 

Dynamic​ ​Menu​ ​generation 

Multiple​ ​menu’s​ ​should​ ​be​ ​able​ ​to​ ​be​ ​generated.​ ​Menu​ ​options​ ​could​ ​feed​ ​dynamically​ ​from  categories/parents​ ​or​ ​be​ ​manually​ ​entered​ ​in.​ ​Dynamic​ ​menu’s​ ​may​ ​have​ ​nesting​ ​levels​ ​to  take​ ​into​ ​consideration.​ ​Menu​ ​items​ ​can​ ​also​ ​be​ ​statically​ ​added. 

Import​ ​functionality 

blanketCMS​ ​should​ ​be​ ​able​ ​to​ ​import​ ​at​ ​least​ ​simple​ ​CSV​ ​files​ ​through​ ​the​ ​web​ ​interface.​ ​More  complicated​ ​imports​ ​should​ ​be​ ​easily​ ​possible​ ​through​ ​system​ ​API’s. 

Thin​ ​bootstrap​ ​for​ ​AJAX​ ​functionality 

AJAX​ ​functionality​ ​will​ ​play​ ​a​ ​large​ ​role​ ​in​ ​the​ ​makeup​ ​of​ ​blanketCMS.​ ​There​ ​should​ ​be​ ​a​ ​thin  enough​ ​bootstrap​ ​that​ ​multiple​ ​consecutive​ ​calls​ ​will​ ​not​ ​bog​ ​down​ ​the​ ​system.​ ​It​ ​is​ ​arguable  that​ ​the​ ​entire​ ​system​ ​boostrap​ ​should​ ​be​ ​thin​ ​enough​ ​that​ ​creating​ ​a​ ​separate​ ​thin​ ​version  would​ ​be​ ​redundant.​ ​The​ ​system​ ​boostrap​ ​should​ ​therefor​ ​be​ ​monitored​ ​closely​ ​so​ ​as​ ​to​ ​not  bog​ ​down​ ​system​ ​initialisation. 

Live​ ​preview​ ​of​ ​content​ ​changes 

Each​ ​content​ ​type​ ​should​ ​be​ ​able​ ​to​ ​be​ ​previewed​ ​on​ ​the​ ​website​ ​before​ ​going​ ​live​ ​so​ ​content  creators​ ​can​ ​see​ ​what​ ​their​ ​changes​ ​will​ ​look​ ​like​ ​using​ ​the​ ​website​ ​template.​ ​If​ ​multiple  themes​ ​are​ ​installed​ ​and​ ​available​ ​for​ ​a​ ​content​ ​type,​ ​these​ ​should​ ​be​ ​able​ ​to​ ​be​ ​toggled. 

Extensive​ ​Permissions 

Admin​ ​actions​ ​should​ ​run​ ​through​ ​an​ ​ACL.​ ​Both​ ​module​ ​access​ ​and​ ​functionality​ ​should​ ​be  able​ ​to​ ​be​ ​defined​ ​by​ ​group​ ​and​ ​user.​ ​Whilst​ ​each​ ​granular​ ​level​ ​should​ ​be​ ​able​ ​to​ ​be  tweaked,​ ​generic​ ​“permission​ ​packs”​ ​which​ ​may​ ​cover​ ​a​ ​variety​ ​of​ ​modules​ ​and​ ​permissions  should​ ​be​ ​able​ ​to​ ​be​ ​defined​ ​and​ ​granted. 

Automatically​ ​triggered​ ​class​ ​intelligence 

When​ ​code​ ​assigns​ ​attributes​ ​to​ ​classes,​ ​there​ ​can​ ​be​ ​a​ ​disconnect​ ​between​ ​when​ ​the  attributes​ ​are​ ​assigned​ ​and​ ​when​ ​they​ ​are​ ​outputted.​ ​One​ ​of​ ​the​ ​best​ ​examples​ ​of​ ​this​ ​is  when​ ​adding​ ​attributes​ ​to​ ​common​ ​areas​ ​such​ ​as​ ​js/css​ ​files​ ​that​ ​should​ ​be​ ​included.​ ​In​ ​other  systems​ ​it​ ​can​ ​be​ ​quite​ ​challenging​ ​to​ ​decipher​ ​where​ ​these​ ​files​ ​have​ ​been​ ​set​ ​to​ ​be  included.​ ​Blanket​ ​will​ ​circumvent​ ​this​ ​by​ ​having​ ​debug​ ​settings​ ​that​ ​show​ ​debug​ ​traces​ ​for  when​ ​these​ ​common​ ​areas​ ​are​ ​added​ ​to​ ​for​ ​easier​ ​debugging. 

Integration​ ​with​ ​Zend​ ​Tool​ ​for​ ​automatic​ ​code​ ​creation 

Zend​ ​Tool​ ​can​ ​be​ ​extended​ ​to​ ​run​ ​custom​ ​code,​ ​and​ ​should​ ​be​ ​extended​ ​to​ ​allow​ ​creation​ ​of  Blanket​ ​specific​ ​Models,​ ​Classes​ ​and​ ​Views.​ ​This​ ​will​ ​greatly​ ​ease​ ​the​ ​use​ ​and​ ​extensibility​ ​of  contributed​ ​code. 

Things​ ​which​ ​would​ ​be​ ​nice​ ​to​ ​have 

Extensive​ ​and​ ​automatic​ ​debugging 

It​ ​would​ ​be​ ​highly​ ​desirable​ ​for​ ​debugging​ ​and​ ​documentation​ ​to​ ​be​ ​automatically​ ​provided.  Model​ ​field​ ​names​ ​and​ ​available​ ​variables​ ​presented​ ​for​ ​themers​ ​is​ ​the​ ​most​ ​obvious  application​ ​of​ ​this. 

In-line​ ​editing​ ​of​ ​page​ ​elements 

When​ ​browsing​ ​the​ ​public​ ​website,​ ​if​ ​sufficient​ ​privileges​ ​are​ ​held,​ ​editing​ ​capabilities​ ​for  titles,​ ​content​ ​and​ ​the​ ​like​ ​should​ ​be​ ​instantiated​ ​by​ ​clicking​ ​on​ ​discrete​ ​edit​ ​links. 

Comments​ ​and​ ​notes 

It​ ​would​ ​be​ ​a​ ​highly​ ​advantageous​ ​feature​ ​to​ ​have​ ​comments​ ​and​ ​notes​ ​on​ ​all​ ​elements.​ ​This  feature,​ ​similar​ ​to​ ​the​ ​review​ ​abilities​ ​of​ ​Microsoft​ ​Word,​ ​would​ ​be​ ​a​ ​great​ ​help​ ​for  collaboration​ ​on​ ​items. 

Things​ ​to​ ​be​ ​discussed  single​ ​node​ ​or​ ​multiple​ ​models  single​ ​node 

-​ ​pros  far​ ​easier​ ​to​ ​have​ ​consistent​ ​editing​ ​interface  menu​ ​creation​ ​becomes​ ​easier  easier​ ​to​ ​define​ ​routes    -​ ​cons  lends​ ​itself​ ​to​ ​fields/field​ ​values​ ​tables​ ​which​ ​can​ ​cause​ ​all​ ​number​ ​of​ ​issues​ ​in​ ​relation​ ​to​ ​db  normalisation​ ​and​ ​moving​ ​objects​ ​from​ ​one​ ​environment​ ​to​ ​another    multiple​ ​models 

-​ ​pros  makes​ ​database​ ​tables​ ​more​ ​logical​ ​as​ ​each​ ​model​ ​has​ ​a​ ​discrete​ ​table​ ​and​ ​column​ ​names  make​ ​much​ ​more​ ​sense    -​ ​cons  menu​ ​creation​ ​becomes​ ​marginally​ ​more​ ​difficult  altering​ ​models​ ​will​ ​rely​ ​on​ ​having​ ​the​ ​ALTER​ ​privilege​ ​in​ ​SQL  cloning​ ​a​ ​model​ ​because​ ​it​ ​is​ ​needed​ ​in​ ​two​ ​slightly​ ​different​ ​ways​ ​becomes​ ​close​ ​to  impossible   

decision:​​ ​decision​ ​deferred​ ​until​ ​more​ ​is​ ​known​ ​about​ ​zf2​ ​setup   

would​ ​blanketCMS​ ​come​ ​packaged​ ​with​ ​modules​ ​like  news/blog/products​ ​or​ ​would​ ​these​ ​be​ ​free​ ​form​ ​created​ ​by​ ​vendors  packaged  -​ ​pros  standard​ ​installation​ ​environment  much​ ​easier​ ​upgrades​ ​for​ ​models    -​ ​cons  wouldn’t​ ​want​ ​to​ ​limit​ ​blanketCMS​ ​to​ ​specific​ ​model​ ​types  could​ ​encourage​ ​multiple​ ​versions​ ​of​ ​similar​ ​models​ ​such​ ​as​ ​galleries,​ ​which​ ​would​ ​lead​ ​to  confusion  could​ ​create​ ​difficult​ ​and/or​ ​bloated​ ​base​ ​installs    decision:​​ ​decision​ ​deferred​ ​until​ ​more​ ​is​ ​known​ ​about​ ​zf2​ ​setup   

store​ ​model​ ​definitions​ ​in​ ​the​ ​db​ ​or​ ​on​ ​the​ ​fs  fs  -​ ​pros  much​ ​easier​ ​to​ ​use​ ​VCS​ ​to​ ​keep​ ​track​ ​of​ ​changes​ ​(alternatively​ ​the​ ​db​ ​created​ ​method​ ​could  write​ ​out​ ​files​ ​to​ ​the​ ​fs​ ​to​ ​get​ ​VC’d)  arguably​ ​quicker​ ​to​ ​write​ ​up​ ​for​ ​technical​ ​people  possible​ ​to​ ​move​ ​from​ ​fs​ ​to​ ​a​ ​web​ ​interface​ ​at​ ​a​ ​later​ ​time  possible​ ​to​ ​change​ ​at​ ​a​ ​later​ ​time    -​ ​cons  harder​ ​learning​ ​curve​ ​for​ ​some​ ​non-technical​ ​users  if​ ​being​ ​written​ ​to​ ​then​ ​permissions​ ​management​ ​becomes​ ​an​ ​issue  extra​ ​tags​ ​for​ ​re-ordering​ ​etc,​ ​if​ ​building​ ​upon​ ​central​ ​files   

should​ ​the​ ​library​ ​files​ ​be​ ​in​ ​a​ ​central​ ​location​ ​or​ ​be​ ​stored​ ​in​ ​each  client​ ​directory  central  -​ ​pros  far​ ​quicker​ ​project​ ​setup​ ​time​ ​as​ ​everything​ ​except​ ​for​ ​client​ ​specific​ ​files​ ​are​ ​not​ ​needed​ ​to 

be​ ​loaded  individual​ ​client​ ​directories​ ​are​ ​much​ ​smaller​ ​as​ ​they​ ​only​ ​need​ ​files​ ​that​ ​specifically​ ​relate​ ​to  their​ ​website,​ ​basically​ ​template​ ​designs​ ​and​ ​any​ ​code​ ​alterations  updates​ ​are​ ​applied​ ​across​ ​all​ ​websites​ ​immediately    -​ ​cons  library​ ​might​ ​have​ ​to​ ​introduce​ ​versioning​ ​into​ ​module​ ​types​ ​to​ ​get​ ​different​ ​functional​ ​types  updates​ ​have​ ​to​ ​be​ ​co-ordinated​ ​if​ ​they​ ​alter​ ​the​ ​database​ ​or​ ​some​ ​other​ ​fundamental  structure    each​ ​directory 

-​ ​pros  module​ ​code​ ​for​ ​each​ ​site​ ​can​ ​be​ ​tampered​ ​with​ ​without​ ​fear​ ​of​ ​altering​ ​other​ ​websites    -​ ​cons  companies​ ​that​ ​manage​ ​many​ ​websites​ ​will​ ​find​ ​it​ ​harder​ ​to​ ​update​ ​many​ ​sites​ ​with​ ​patches;  can​ ​be​ ​mitigated​ ​with​ ​auto-notifications​ ​of​ ​updates​ ​and​ ​auto​ ​update​ ​install    decision:​​ ​if​ ​possible,​ ​a​ ​choice​ ​of​ ​installation​ ​would​ ​be​ ​presented,​ ​either​ ​drawing​ ​from​ ​a  central​ ​codebase​ ​or​ ​using​ ​just​ ​use​ ​the​ ​modules​ ​necessary​ ​for​ ​the​ ​site​ ​to​ ​run.  additionally,​ ​a​ ​central,​ ​WHM​ ​as​ ​to​ ​cPanel,​ ​type​ ​console​ ​could​ ​be​ ​made​ ​that​ ​maintains  managed​ ​sites,​ ​altering​ ​content,​ ​installing​ ​plugins,​ ​upgrading​ ​software​ ​etc​ ​etc.​ ​This,​ ​whilst  being​ ​planned,​ ​would​ ​not​ ​be​ ​rolled​ ​out​ ​in​ ​the​ ​first​ ​phase​ ​for​ ​obvious​ ​logistical​ ​reasons