Do you get the same error on both types of blocks? Have you deleted the Flickr block manually through ftp (or any file manager) without uninstalling it from the c5 dashboard?

Typically this type of error messages shows up when a block is missing it's files but are still requested via the database. You could reupload the flickr block and see if that solves your problem with reaching 'dashboard/blocks/types/'.

If you can reach your Block Types, then I suggest you delete the Flickr block (or package, if it's an add-on) through the dashboard before removing the actual files.

thanks adajad for your quick answer.

I decided to reinstall all stuff. Reinstalling concrete5 and a new DB.
I pick up the block_test in the documentation.
I unzipped it and place it in my webroot/blocks
And the same problem appear when I try to access to blocks/types through Admin panel
----
When I move the basic_test into webroot/concrete/blocks the access to blocks/types is correct. (No Php error)

It seems that C5 tries to parse the basic_test into its core's blocks. And failed. For sure it is located into my webroot/blocks

Strange is it.

I do a complete installation (I like it but it begins to be boring ...) on a Pc with Wamp (Windows 7)
And it works perfectly.

Then the problem comes from the installation on MAMP / OS Lion.

And I'm enable to know where is the problem ....

You could try installing the designer content addon and generating a simple block with that. See if you still get a problem.

That will confirm if it is your installation or your block that has the glitch.

One big difference between WAMP and MAMP/LAMP is case sensitivity. So you should also check correct case for the block file names and controller class name.

Thanks for your hint JohnTheFish.
1- I discover this super add-on
2- When I create a block thanks to this package then everything works great.

Nevertheless I do not understand why.
The code seems to be the same.

Thanks again

I have unfortunatly to continue the thread.

Doing a Block Type via the DesignerContent Add on leads to have code in webroot/blocks
And when accessing via admin block / types is correct NOW.

But I do another test: I duplicate the code and rename the controller name and the directory.

Then when I try to access admin / block / types it fails as the first time.

The code is similar. But the process is not. On the first test the Add on register the block itself, and in the second test C5 parses and aims to propose the block to be registered or not (via admin / blocks / types

I suspect inconsistencies between the block name, the block database xml, the file paths and names and the controller class name. These all have to tie up according to specific rules on capitalisation, case and underscores. Any breaking of the rules could lead to blocks not working or showing up where they are supposed to.

You also need at least one field in the block db.xml other than the id, even if it is just a dummy.

The rules are explained on this site in the developer guide and various howtos. Or you could get a copy of Remo's book.

Designer content has all these rules built in. For many who develop the occasional ad-hoc block, the easy solution is to create a skeleton for it with designer content then edit the result. That way, all this stuff stays consistent. It also outputs better code than many of the old core blocks that carry the legacy of how c5 was built several years ago, so you have a better example to follow.

But the rules are respected.
And the code is very small. very very small

There is no xml, just a controller and a view.

Your zip file is missing the db.xml associated with the blocks. I don't know if a block can exist without a database table to hold its instances.

Thanks to have had a look on the archive.

The first one (Essai) was created thanks to the Designer Content then I suppose that it is possible.

db.xml was needed when there is state to store. Essai was just a try with just a view containing a header tag.

I go deeper in the C5 code.

All stuff is located in core/libraries/Environment.php
in the getRecord($segment,$pkgHandle)

the difference there is between a Block Type created or copied "byHand" and the one's created with the "Designer Content" is that for the firsts they are not registered in $this->coreOverrides
an array where the path of blocks are registered.
And then the Path created for accessing to Blocks Types are not correct.

For the first one system attempts to locate them in concrete core and for the second in the correct location webroot/blocks

But i'm totally unable to know which processes is in charge to populate the array Environment::coreOverrides....

In this Environment::getRecord($segment, $pkgHandle = false)

if i perform a $this->clearOverrideCache(); at the beginning of this method

Then it works correctly and the admin block Types panels appears with new blocks to install.

And also I have the same trouble when I try to create a single page.
Creating a controller, a model and a view

C5 is scanning the core and NOT my webroot. And then It leads to error because it doen't find the model in concrete/core/models

The way to make it works it to use the Environment::clearOverrideCache()
It forces C5 to scan application directories and not only core directories.

But I'm very surprising because I expected this works without using this public Environment method.
I search whether this method is used in the core ... never used.

I think I may have spotted what you are missing. For both standalone blocks and single pages you need to tell c5 that they exist. There are dashboard interfaces for doing both.

Packages do the same, but with code in the package controller. For standalone blocks and single pages, you have to go into the dashboard and do it by hand.

Really thanks, JohntheFish. I really appreciate your help.

Yes I know that we have to pass through the dashboard, but the problem is that. I can't access to it.
I go further with the problem. I create a single page with a controller, a model, and a view.
I create the controller: just the wrapper (name, declaration ...)
I create the model
I create a view with nothing inside.
I follow this guide which helps me a lot :http://www.eantics.co.uk/whats-fresh/mvc-in-concrete5/...

I follow the instructions with great attention. I have NO DOUBT about the problem comes from the difference between MacOs and Windows (because with a fresh windows install and same instructions EVERYTHING works well)

For both platforms I register my single page inside dashboard

Results : on Mac same problem. C5 doesn't scan my webroots. and so I get a failed open stream from the core.
Once again I spotted the code. It is in Environment. A clear cache is not made, then the getPath method give core directories to scan the model, etc ...

on PC, no problem. My single page is registered and when I access it through browser it works like a charm.

I follow the hints you gave me regarding coding rules/conventions.

I'm really sad because I would really appreciate to go on C5. Which I found very interesting due to the great effort made on object oriented and MVC approach.
Regarding to the Drupal approach, it makes my brain happy.
But I admit that F... problem of inconsitency between MAc and Windows is very troubling me.

I'm not the only one to develop on Mac i suppose... But no thread concerning this problem.

Have a good day

C5 works in Linux, which is case sensitive. There are other c5 developers using macs.

I would only risk concluding it is a c5/mac incompatibility if you had also tested in Linux and found it to work correctly as it does in Windows. If it fails in Linux, then you have a capitalisation mistake. if it works in Linux, then maybe there is an environment setting upsetting things on your MAMP install. Only with all that excluded would I conclude a mac compatibility bug.

Personally I always develop in packages, even if it is a one off. It gives me direct control of install and uninstall, and I can code in some diagnostics if I get problems.

Looking at the blog you are following, the model filename should also be aardvark.php, not aardvarkModel.php.

However, as models are optional, in a bare minimum single page that may not be significant until you try and load the model.

I perform a fresh install (I take the opportunity to claim to the community, that I'm the master a lot the installation of C5. 5 installation in 2 days and half. I 'm candidate to the cup of the world).

Then fresh install on linux server.
And same problem as I got on MacOs.

Then problem on capitalization.
I investigate

Remember one test I made : this is very very strange.

I use the "Designer content" package to create block. (So not made by HAND)

--> On my Mac it works, the block appears in the dashboard/block types.
But this block is already installed. I would supposed that the bloc freshly created would be just in available and not installed ....(First Remark)

---> I do the same on linux => Same result
=================================
Both for Mac and Linux I suppress in the Package "Designer content" the line which is in charge to register. I keep the creation of the block.
(it is packages/designer_content/controllers/dashboard/blocks/designer_content.php line 106)

And then when I create another block on the 2 platforms, it fails both.

I conclude that maybe it is not a simple question of capitalization.
The "Designer Content" create the block BUT ALSO register it. Up to me it is why it works.
But when It doesn't make the registration, it fails AS the code performed by hand (and for sure not registered)


I think this problem occurs when you create a block. Not when you override an existing block of the core.