CiviCRM Community Forums (archive)

I'm currently working on the Drupal 8 port, and one of the pain points I'm encountering might be relatively easy to fix.

At the moment there are two main entry points into CiviCRM — one is via the CMS which initializes CiviCRM, and the other is by directly calling a CiviCRM php file. In the latter case, it will sometimes be necessary to bootstrap the CMS to do user validation checks, etc. In CRM/Utils/System/{CMS}.php there's a fair bit of really quite ugly code handling this alternative, back-to-front bootstrapping. It seems to me that settling on a single code path would result in more reliable and better tested code.

My proposal is to ensure the only entry point into CiviCRM is by way of the CMS, ie. the CMS will already be bootstrapped. Alternatively, leave the 'naked' php files in CiviCRM as they are but change those that require the CMS to be bootstrapped to go in via the CMS first.

I presume the reason for the naked PHP files is performance, but things like cron, migrations, etc. aren't so time critical that an extra ~300ms of CMS bootstrapping up front is going to cause issues. And at least in Drupal 8, bootstrapping the system is much less expensive now thanks to lazy loading much of the system — especially if CiviCRM could let the CMS know ahead of time (ie. as a flag in the civicrm_menu table) when a request is  full HTML response or whether its simply json/xml/etc.

From a brief bit of grepping, the files that require bootstrapping the CMS or authenticated against the CMS are:

• bin/cli.class.php
• bin/cleanup42
• bin/ContributionProcessor.php
• lots in bin/deprecated/%
• bin/encryptDB.php
• bin/migrate/export.php
• bin/migrate/exportJSON.php
• bin/migrate/import.php
• bin/migrate/importJSON.php
• bin/migrate/move.php
• CRM/Utils/SoapServer

I'm curious to know how people feel about this, and in particular whether this would make other CMS maintainer's (eg. WP, J!) lives easier too.

+1 for minimising entry points. In my nginx deployment I heavily restrict what files can be run under php to minimise risk. The fewer number of files I need to list the better (and when I initially implemented this a number of things kind of broke silently because I hadn't whitelisted all the extern/*php scripts).