A few questions about porting packages and themes to 5.7
Permalink
Howdy all,
With the release of the 5.7 beta, I've started looking at what is required to update existing packages and themes. So far I've got most of my List Files From Set block working in 5.7, there are just a few internal changes to work through (pagination results, etc).
From this I've formed a few questions, my apologies if these have been covered elsewhere.
1 - When blocks are created, an icon.png file is referenced for its icon. In 5.7 these icons are now larger and purely blue. Should we be creating our custom block icons to match this blue colouring, or should we stick to having them full colour (but just larger than before)?
2 - When I installed a 5.6 theme, this installed fine, but when used threw the error "Call to a member function getPageThemeGridFrameworkRowStartHTML() on a non-object" in /concrete/blocks/core_area_layout/view_grid.php
Do we need to do something extra with themes to define a grid or framework? (or is this just a bug and I need to update my c5.7 install from github..?)
3 - I've mostly got my head around using 'use' statements to autoload classes and make them available in the current namespace. I'm still seeing things loaded in ways like:
$e = Loader::helper('validation/error');
Should something like this be replaced with a newer equivalent for example?
4 - I've referred to Andrew's guide about 5.7 migrations here:http://www.concrete5.org/documentation/how-tos/developers/concrete5...
Are there other sources of doco I should be referring to, to understand the differences and changes needed?
5 - More broadly speaking, has there been any announcement about the direction of eCommerce in terms of 5.7? I'm sort of hoping this too gets the same sort of treatment as the core, code cleanup, simplification, etc.
Cheers
-Ryan
With the release of the 5.7 beta, I've started looking at what is required to update existing packages and themes. So far I've got most of my List Files From Set block working in 5.7, there are just a few internal changes to work through (pagination results, etc).
From this I've formed a few questions, my apologies if these have been covered elsewhere.
1 - When blocks are created, an icon.png file is referenced for its icon. In 5.7 these icons are now larger and purely blue. Should we be creating our custom block icons to match this blue colouring, or should we stick to having them full colour (but just larger than before)?
2 - When I installed a 5.6 theme, this installed fine, but when used threw the error "Call to a member function getPageThemeGridFrameworkRowStartHTML() on a non-object" in /concrete/blocks/core_area_layout/view_grid.php
Do we need to do something extra with themes to define a grid or framework? (or is this just a bug and I need to update my c5.7 install from github..?)
3 - I've mostly got my head around using 'use' statements to autoload classes and make them available in the current namespace. I'm still seeing things loaded in ways like:
$e = Loader::helper('validation/error');
Should something like this be replaced with a newer equivalent for example?
4 - I've referred to Andrew's guide about 5.7 migrations here:http://www.concrete5.org/documentation/how-tos/developers/concrete5...
Are there other sources of doco I should be referring to, to understand the differences and changes needed?
5 - More broadly speaking, has there been any announcement about the direction of eCommerce in terms of 5.7? I'm sort of hoping this too gets the same sort of treatment as the core, code cleanup, simplification, etc.
Cheers
-Ryan
Helpers:
Here is what I ended up doing. Really took some time and some pointers from Andrew:
in my package controller:
ProeventsServiceProvider:
Hope this helps.
ChadStrat
Here is what I ended up doing. Really took some time and some pointers from Andrew:
in my package controller:
use \Concrete\Package\Proevents\Helper\ProeventsServiceProvider as ProeventsServiceProvider; class Controller extends Package { .... public function registerHelpers() { ProeventsServiceProvider::register(); } public function on_start(){ $this->registerHelpers(); } .... }
ProeventsServiceProvider:
<?php namespace Concrete\Package\Proevents\Helper; use Core; use \Concrete\Core\Foundation\Service\Provider as ServiceProvider; class ProeventsServiceProvider extends ServiceProvider { public function register() { Core::bind('helper/eventify', function() { return new \Concrete\Package\Proevents\Helper\Eventify;}); Core::bind('helper/form/time', function() { return new \Concrete\Package\Proevents\Helper\Form\Time;}); Core::bind('helper/form/datetimetime', function() { return new \Concrete\Package\Proevents\Helper\Form\Datetimetime;}); } }
Hope this helps.
ChadStrat
This does help, thanks Chad (and Joe).
now if I can just figure out the best/most optimal way to approach AJAX block views in 5.7....sigh....
ChadStrat
ChadStrat
> now if I can just figure out the best/most optimal way to approach
> AJAX block views in 5.7....sigh....
Chad,
It seems that package tools files are broken in 5.7. But who wants to use the old deprecated approach anyway. Here's what works for me:
In the on_start() handler of your package controller, register a custom route...
Then, inside your block's directory, create a folder called "ajax" (or whatever, but change path above to match), and inside it place a file called "classname.php" containing the implementation of the "Classname" class, which should implement "method()". For example, classname.php might look like...
Now when you visit...
mysite.com/index.php/my/custom/route
...the method is invoked.
While this works, I have no idea if it's the officially sanctioned way to go about it - mainly because you can name your route absolutely anything, and that seems to open the possibility of route collisions. That's what prompted the following post...
http://www.concrete5.org/community/forums/5-7-discussion/implementi...
Let us know if you learn anything else.
-Steve
> AJAX block views in 5.7....sigh....
Chad,
It seems that package tools files are broken in 5.7. But who wants to use the old deprecated approach anyway. Here's what works for me:
In the on_start() handler of your package controller, register a custom route...
public function on_start() { Route::register('/my/custom/route', '\Concrete\Package\MyPackage\Block\MyBlock\Ajax\Classname::method'); }
Then, inside your block's directory, create a folder called "ajax" (or whatever, but change path above to match), and inside it place a file called "classname.php" containing the implementation of the "Classname" class, which should implement "method()". For example, classname.php might look like...
Now when you visit...
mysite.com/index.php/my/custom/route
...the method is invoked.
While this works, I have no idea if it's the officially sanctioned way to go about it - mainly because you can name your route absolutely anything, and that seems to open the possibility of route collisions. That's what prompted the following post...
http://www.concrete5.org/community/forums/5-7-discussion/implementi...
Let us know if you learn anything else.
-Steve
I suppose you could just use a method in your existing block controller instead of creating a separate AJAX controller file, but the issue of route "collisions" (co-opting) remains.
-Steve
-Steve
@Shotster - good thoughts. I kinda like having the separate route for this. I think it's a good idea for an informal route path though specific to block views.
Couple of thoughts:
1) /package/blocks/blockname/controllers/ajax_controller.php as a possible option? or perhaps /package/blocks/blockname/controllers/controllername/controller.php (maybe better as other related files can be grouped that way) ? I'd really be in favor of doing away with "tools" as that concept is gone all together.
2) in this same vein, package non-block specific controllers can simply go in /packages/controllers/ or /packages/controllers/controllername/
3) what is the outlook on overriding these routes in the root moving forward? Simple edit your /application/config/app.php? And that will supersede any defined package routes?
ChadStrat
Couple of thoughts:
1) /package/blocks/blockname/controllers/ajax_controller.php as a possible option? or perhaps /package/blocks/blockname/controllers/controllername/controller.php (maybe better as other related files can be grouped that way) ? I'd really be in favor of doing away with "tools" as that concept is gone all together.
2) in this same vein, package non-block specific controllers can simply go in /packages/controllers/ or /packages/controllers/controllername/
3) what is the outlook on overriding these routes in the root moving forward? Simple edit your /application/config/app.php? And that will supersede any defined package routes?
ChadStrat
As such controller routes could be used for things other than browser ajax requests, I have a preference for including /ajax/ in the convention to distinguish from other routes.
/packagename/blocks/blockname/controllers/ajax/controllername/controller.php
/packagename/controllers/ajax/controllername/controller.php
- though these are getting a bit long winded, so anything to cut it down while keeping the classification distinctions would be an improvement.
/packagename/blocks/blockname/controllers/ajax/controllername/controller.php
/packagename/controllers/ajax/controllername/controller.php
- though these are getting a bit long winded, so anything to cut it down while keeping the classification distinctions would be an improvement.
> 3) what is the outlook on overriding these routes in the
> root moving forward? Simple edit your /application/config/app.php?
> And that will supersede any defined package routes?
I haven't actually tried it yet, but based upon the order in which things are loaded during the bootstrap process, it appears to be just the opposite - i.e. that package-defined routes will override app-level routes having the same route path.
-Steve
> root moving forward? Simple edit your /application/config/app.php?
> And that will supersede any defined package routes?
I haven't actually tried it yet, but based upon the order in which things are loaded during the bootstrap process, it appears to be just the opposite - i.e. that package-defined routes will override app-level routes having the same route path.
-Steve
Maybe the Ajax controller should be calling in a package element for render? But then I haven't messed with overriding package elements either. But perhaps that makes more sense. I did get ProEvents Ajax calendars working well. So thanks for the idea on that!
ChadStrat
ChadStrat
I've got routes registering properly in my package controller, but I'm wondering if there's a way to route just to a controller, rather than specifically to a method of a controller - basically how single pages work, but without a single page.
For example:
This would then allow me to access any method within the {controller-name} class via the example.com/{package-name}/{controller-name}/{method}. Is this possible?
For example:
Route::register('/{package-name}/{controller-name}', '\Concrete\Package\{package-name}\Controller\{controller-name}');
This would then allow me to access any method within the {controller-name} class via the example.com/{package-name}/{controller-name}/{method}. Is this possible?
echo $controller->action('my_action').. I miss you !!!!!
Working with AJAX from block view seems tooooooo complicated ! :-(
Working with AJAX from block view seems tooooooo complicated ! :-(
I don't have many answers as I haven't done any theme migrations myself yet, but for another resource you could check outhttps://github.com/concrete5/concrete5-5.7.0/wiki/Migration-Guide,... started by @jordanlev. Hopefully you'll find that somewhat useful, please feel free to add / make changes to it if you come across any useful additions that might help others.
As far as the helper stuff, I think the "new" way of doing that is using the Core::make function, but I haven't looked into that much either, I believe that you would need to do something like this: