5.7 Custom Block Development

Permalink
Does anyone have an 'idiots guide to custom block development in 5.7' that they might be able to share with me? I only JUST started to grasp pre-5.7 process albeit badly I'm sure.

I cannot get my most simple block to work in 5.7 and i think it has something to do with the 'namespaces'. It is really just a block that forces its contents into a specific css class.

Anyway... this is what it looked like before...
defined('C5_EXECUTE') or die("Access Denied.");
   class BookawardBlockController extends Concrete5_Controller_Block_Content {
      protected $btTable = 'btBookaward';
      protected $btInterfaceWidth = "600";
      protected $btInterfaceHeight = "46.......


I have it in application/blocks/bookaward
and so i tried this... (which I based off of a how-to from c5)

namespace Application\Blocks\Bookaward;
     use \Concrete\Core\Block\BlockController;
//use UserInfo;
use Loader;
//use \Concrete\Application\Blocks\BookAward as BookAward;
//use Config;
//use Page;
//use View;
class Controller extends BlockController {      
      protected $btTable = 'btBookaward';
      protected $btInterfaceWidth = "600";
      protected $btInterfaceHeight = "465......


(note: i would comment out certain items and see if it stops the error. hence the mess above)

So you may have guessed, I am a designer not a programmer. And as such i am having trouble grasping this... like "use View;"... what's View? The view.php file in the block folder? Might be a logical assumption but there's no "loader.php" file in the same directory of the example. Is this required in every custom block?

View Replies:
Chrouglas replied on at Permalink Reply
dumbed into it by changing 'blocks' to block. deleted all the 'use' and it worked.
now more complicated (in my use of the word) blocks that (use to) tap into the core content block now only add... edit but don't commit edit changes to db.
MrKDilkington replied on at Permalink Reply
MrKDilkington
philipemerson replied on at Permalink Reply
philipemerson
I have to say, if you were looking for a way to drive away your community of loyal developers, you've found the holy grail.

Completely changing the way that blocks are written and then releasing the CMS without any CLEAR documentation telling us how to rewrite all of our previous assets for the sites we have to build to deadlines is unbelievable.

I've been recommending Concrete5 because of its strengths but no longer feel able to do so.

I'm unable to finish a website because I have no idea how to convert my existing assets to the new programming model. Telling us that documentation is on the way doesn't help us to meet the deadlines we have now!

I can't speak for other developers but I don't have the time to dig through all of the rewritten C5 blocks and try to figure out what it is you've done.
axiandev replied on at Permalink Reply
axiandev
Agreed. This is driving me insane. Would love to see some completed documentation. Particularly on block development. The available documentation is sorely lacking.
jshannon replied on at Permalink Reply
jshannon
Speaking as someone who has checked back into the community recently after being gone a few months, the effect has been palpable.
MrKDilkington replied on at Permalink Reply
MrKDilkington
I agree, lack of documentation is a significant issue. It is holding back the rate of improvements and overall adoption and growth.

That said, I do understand the position the core team is in. As far as I can tell, the core team consists of just Andrew and Korvin. They are under a lot of pressure to develop and document at the same time. It makes sense that they can't do both right now.

Please take a minute to read this thread relating to community documentation efforts.
http://www.concrete5.org/community/forums/documentation_efforts/tow...

As an open source project, there is where the community can come in. We show the core team that if they provide the basic documentation, we can take it from there. That with enough people contributing, we can create rich and diverse expanded documentation.

I am sure that many people might feel that they don't have strong enough programming skills to contribute to documentation (or may not even be programmers). We are dealing with a CMS, so this is the exact opposite case. Many of the non-programmers are best suited to create documentation - they are the web designers, people making a living distilling and presenting information.

Concrete5 is someone's baby and they are very protective of it and the years they have invested in it. But to make it better and grow, more community input and code contribution needs to be accepted.
Sadu replied on at Permalink Reply
Sadu
This is exactly the problem.

I have used C5 almost exclusively for about 3 years but I'm just finding it hard to get excited over the new improvements when I can't meet deadlines anymore. I'm all for improving things and I can deal with a bit of upgrade pain if necessary, but going +100% over quote on jobs is a show stopper for us. We need to be able to learn the new tools but the business needs to remain profitable first and foremost.

I appreciate that documentation is coming and the community will at some point get behind 5.7 and the addons will come, but I'm real concerned about what happens in the meantime. Although a great product, it's hard to recommend 5.6 to a client knowing that it's future is limited and an expensive rebuild will be necessary in 12-18 months time. But equally hard to recommend 5.7 knowing that a 100% budget blowout is the likely outcome.

Have to say I'm feeling a bit lost here.
mesuva replied on at Permalink Reply
mesuva
I'm curious here, if a site is complete, stable and working well, why do you see a rebuild as necessary for a 5.6 site in 12-18 months time?
Sadu replied on at Permalink Reply
Sadu
Security, mainly. My experience is that if you don't update your OS CMS site every 6-12 months it runs a high risk of getting hacked. I have been around long enough to have this happen on wordpress, magento, joomla, and bespoke projects and it's a nightmare to fix. Its not just the CMS you have to worry about, sometimes its the wysiwyg editor or some internal component that is the source of the hack. A good cms will maintain updates on these internal components as part of their upgrade cycle. So in my view it's high risk to keep running 5.6 once the updates stop.

But also I have really appreciated the micro updates to the C5 core over the years. The new features and bug fixes are always welcome and I wouldn't want to develop on a platform that is no longer getting those updates. It seems wrong to me to recommend a solution to a client that is basically end of life.
mesuva replied on at Permalink Reply
mesuva
I don't disagree with you on any of those points of risk, it's important that software is kept up to date. I've also seen the mess of Joomla hacks and what-not.

But on the other hand, 5.6 is _very_ mature software that has been heavily debugged, patched, analysed and road-tested. It's also on github, where many people continue to work on it because they are wanting it to continue. Fixes and patches will be available there, and since concrete is all self contained in one folder pretty much, it shouldn't be hard to keep sites up to date.

My experience is that overall concrete5 is a very secure system and if you look across the version histories there's actually very few security fixes, most of them being XSS related I reckon. I'm yet to have read about ANY concrete5 specific hack.

I just kind of think there's a false sense of security that 'latest' = most secure. Something with heavily changing code is going to have more bugs in it, therefore more potential security exploits. I also think that if some major security issue is found with 5.6 in the future, energy will be put towards resolving it and putting out a bugfix release - it's in everyone's interests for concrete5 to not end up with a bad reputation security wise.

I guess I'm saying I don't see the 5.6.x branch of concrete5 as outdated just because 5.7 is out, I just see these as two different systems. 5.7 is where all the new shiny stuff is being added, where 5.6 is where it's a 'finished' system feature wise, but it'll continue on being updated via github.

I'd personally prefer the term 'classic' over legacy when referring to 5.6 as the word legacy seems to have negative connotations, and I don't have any negative thoughts on 5.6 - it's pretty damn awesome.

Not trying to be argumentative as such, just sharing my thoughts!
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
+1 to Mesuva
There is also the point that having spent a long time training the client and the clients other users on how to use 5.6.
"Upgrading" to 5.7 means having to train the end users all over again and I find that many people do not like change especially if they have struggled to learn 5.6 in the first place.
I think many users will say "Why change to 5.7 when we are happy with 5.6 and it works fine"
Sadu replied on at Permalink Reply
Sadu
To Concrete5's credit we have never had a C5 site hacked. We had one server which was being targeted specifically and a bunch of Wordpress sites (even latest version ones) fell over like flies. Never had a single problem with a C5 site on the same server. So credit where credit is due and I do agree that 5.6 is mature and stable.

I really like 5.6 as a platform. What appeals in particular is that a half-decent dev can quickly whip up some custom blocks or custom templates to fill a particular customer need, customer is happy, devs can make some money on the job and the system is stable enough that there's no massive support nightmare afterwards. C5 has been flexible enough that you can usually say yes to whatever ideas the customer has after the initial build is complete. Additionally the addons tend to be better quality and more upgrade resistant than free ones you get with Wordpress. And the page list block is seriously the best thing ever - the range of stuff I have built with the page list block is mind-blowing.

Having tried 5.7 on 2 projects now it doesn't (at the moment) tick any of the boxes that 5.6 does.
So for me, sticking with 5.6 seems the reasonable choice and I'm one of those who thinks it works fine (although there's more I'd like to see done with it). But yeah I do have concerns about what happens to 5.6 down the road, 1-2 years from now. If a client is paying $10k for a site they need it to last and be supported longer than 1-2 years. Certainly 5.6 is not going to get the same attention from core devs it did previously, and that's a negative. Security wise, you are probably correct and it will probably be fine with minimal attention.

I'm not trying to be negative or critical here, but I think these concerns are reasonable.