Can't find the site 'blocks' folder after moving custom block to live


Developed new contact form block and put it under 'htdocs/blocks/form' folder, worked perfectly on local dev, however once move it to live on Bitnami, it keeps looking for it under 'htdocs/concrete/blocks/form' folder:

Warning: require_once(/opt/bitnami/apps/concrete5/htdocs/concrete/blocks/form/controller.php): failed to open stream: No such file or directory in /opt/bitnami/apps/concrete5/htdocs/concrete/core/libraries/loader.php on line 217

Can you enlighten me which config i missed or where i should look for to point it to ' 'htdocs/blocks/' folder instead of ' 'htdocs/concrete/blocks/' on Bitnami?


View Replies:
hutman replied on at Permalink Reply
First, there is already a core block called form, so that may mess up your custom block, unless you are making changes to the core block.

When you moved the files for your block from your dev environment to live did you install the block on the live site?

What are you doing when you get this error?
zucvv replied on at Permalink Reply
Didn't install the block on the live site, how do i do that? thought moving the code file along with the database import script, no install would be required?

Got the error when loading the page containing the block.

mhawke replied on at Permalink Reply
Concrete5 looks in several places for files and when it fails to find the file it reports the last place it looked which is in the concrete folder.

I agree with hutman that putting stuff inside the block/form folder is asking for trouble. Forms in concrete5 require controllers to handle the form's submission. Does your contact block have a controller.php file?
zucvv replied on at Permalink Reply
yeah, the contact block does have a controller.php:

defined('C5_EXECUTE') or die("Access Denied.");

class FormBlockController extends Concrete5_Controller_Block_Form {

//users submits the completed survey
function action_contact_form() {

$ip = Loader::helper('validation/ip');

Also in the form_setup_html.php:
defined('C5_EXECUTE') or die("Access Denied.");
/* @var $uh ConcreteUrlsHelper */
$uh = Loader::helper('concrete/urls');
/* @var $form FormHelper */
$form = Loader::helper('form');
/* @var $ih ConcreteInterfaceHelper */
$ih = Loader::helper('concrete/interface');

seems like the Loader::helper('form') not loading the proper 'blocks/form' and loading the 'concrete/blocks/form' instead.

mhawke replied on at Permalink Reply
Have you tried the 'External Form'. I have built several but I know others do not like using the 'External Form' route.

Have a look at this package created by Jordanlev
sthaigh replied on at Permalink Reply
While testing a site on a Bitnami VM, I have run into a similar problem. However the suggestions in this thread does not answer zucvv's original question. "it (C5) keeps looking in the [root]/concrete/blocks/form folder". From my experience C5 should look in the override location before looking in the core. This is how C5 was designed, am I wrong!?

That being said, does anyone have an idea what the issue could be? I'm thinking it must be a server configuration, but I haven't been able to find any relevant post or documentation on the optimal Apache server settings to use with concrete5.

Any insight is helpful & thanks ...

Thanks & cheers
mhawke replied on at Permalink Reply
Taking the 'form' example above, the error you see refers to the concrete/blocks/form path because that is the last place it looks. In my experience, it's usually caused by a path in your code that is not correct. Concrete5 looks in the [root]/blocks/form folder first and when it cannot find the resource in that path, it continues to move up the 'food chain' until it finally searches all possible locations for the resource and ends up in the concrete/blocks/form folder when it generates the error. Until it runs out of places to look, there is no error.