5.7 Add-On Developers Guide, Part 1

Permalink 3 users found helpful
I just posted a how-to detailing how I got a simple free add-on (from jordanlev, thanks!) ready for 5.7:

http://andrewembler.com/posts/concrete5-5-7-add-on-development-part...

It's also cross-posted here for posterity:

http://www.concrete5.org/documentation/how-tos/developers/concrete5...

Thanks! 5.7 is still very much a work in progress so as you undertake migrating to it you might find certain aspects of it half-done. Please post issues here as you uncover them:

https://github.com/concrete5/concrete5-5.7.0...
Thanks everyone.

andrew
 
JohntheFish replied on at Permalink Reply
JohntheFish
Is the full source for the 5.7 updated addon posted anywhere?
andrew replied on at Permalink Reply
andrew
I am getting approval from Jordan to post the updated addon

Sent from my iPhone

> On Apr 23, 2014, at 12:16 AM, concrete5 Community <discussions@concretecms.com> wrote:
RadiantWeb replied on at Permalink Reply
RadiantWeb
We need the ability to hide the dashboard slideout pane. Little buggy right now if you simply click the dashboard icon when on a dashboard page, and the css of the page does not compensate/adjust when you do get it to slideout.

C
RadiantWeb replied on at Permalink Reply
RadiantWeb
Andrew, do we need to change a packages db.xml at all? is that gone now? how do we initiate package db's now?

I keep getting type errors, I changed all the "type" attributes tohttp://doctrine-dbal.readthedocs.org/en/latest/reference/types.html... to no avail.

C
RadiantWeb replied on at Permalink Reply
RadiantWeb
Figured this out, I had a db field posting "Time" instead of "T". No issue here.

C
RadiantWeb replied on at Permalink Reply
RadiantWeb
\Concrete\Core\Attribute\Set needs :

use \Concrete\Core\Attribute\Set as AttributeSet;


C
RadiantWeb replied on at Permalink Reply
RadiantWeb
Not seeing a way to load up package helpers needed for custom attribute types.

Looks like /concrete/core/legacy/loader.php helper() allows for passing a $pkg but does not rout properly.

What should our package folder structure be for helpers now? follow your new widget format or stick with the old /helper/form path?

Moved attribute types into /package_name/attribute/ and was able to successfully install.

Running into bugs with page_types not allowing a save of "chose location".

C
RadiantWeb replied on at Permalink Reply
RadiantWeb
I changed the legacy loader helper method to:

public static function helper($service, $pkgHandle = false) {
      if($pkgHandle){
         return Core::make('/packages/'.$pkgHandle.'/helper/' . $service);
      }else{
         return Core::make('helper/' . $service);
      }
   }


I'm not sure if this is correct.

Should the helper class namespacing be:

namespace Concrete\Package\Proevents\Helper\Form;


OR

namespace \Packages\Proevents\Helper\Form;


C
RadiantWeb replied on at Permalink Reply
RadiantWeb
Got around this by using:

use \Concrete\Package\Proevents\Helper\Form\DateTimeTime as DateTimeTimeHelper;
$dtt = new DateTimeTimeHelper();


C
RadiantWeb replied on at Permalink Reply
RadiantWeb
Package custom attribute types have a few issues:

- installer not seeing package custom attribute db.xml
- package helpers need help
- custom attributes do not seem to see and render form.php, only method form();

C
andrew replied on at Permalink Reply
andrew
FYI: part two has been posted:

http://andrewembler.com/posts/concrete5-57-add-on-development-part-...

Jordan has graciously allowed me to post the updated source of the add-on, which is in the blog post.
DavidMIRV replied on at Permalink Reply
DavidMIRV
How do helpers now fit into the new scheme of things ?
I've been perusing the new core and I can't for the life of me figure out the new development pattern for them .. ?
andrew replied on at Permalink Reply
andrew
In general, most helpers should be still available as Service Objects. You can make them with the legacy Loader::helper('path/to/whatever') or the new Core::make('helper/path/to/whatever');. They're not really referred to as helpers any longer – just services that you can get to at special paths. We're adding a full listing of these and where they point to in the appendix of the currently-in-development developer docs.
DavidMIRV replied on at Permalink Reply
DavidMIRV
Gotcha, I was able to make the helpers work by conforming to the PSR4 and simply using them .. The Core::make did not work at all for me though ..
DavidMIRV replied on at Permalink Reply
DavidMIRV
are we left with resorting to include/require for non PSR-4 compliant 3rd party libraries ? (Google API)