-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Add extension capability #8
Comments
NEW (#8): Ability to apply grid field capability to pages via DataExtension
Very nice, thanks for this! I've been wanting to revisit this module for a while now. I've just merged your PR into master. Will test a bit and indeed create a 2.0 tag, maybe including some other functionality as well; Only thing now is probably that I'd like to remove the GridFieldPage class altogether and just include it as an example of implementation. What do you think? |
Welcome! Been using this for a few years now (edit: proof!) on a site with thousands of pages, myself. I've recently needed to incorporate yet another area with a particular page type that could have hundreds of pages in the long term, so
You completely lost me there! What is this "lumberjack" you speak of?
i.e. do you mean to go extension only, then to recommend that if a user wishes to apply via built-in class inheritance that they take the standard SS extension (e.g. apply via NOTE: I'm not sure if it's possible to disable an extension for child classes, but if it were, that'd be another advantage to going |
Also, actually, I've been using If you're listing pages in a I've also created my own This code goes int' the // Initialize data that we'll use to pass to our controller which actually does the real heavy lifting.
$data = [
'PageType' => $gridField->getModelClass(),
'ParentID' => $this->getParentID(),
];
// Just so we have an instance to pass (would be required if there's a validation error). This just prevents crashing.
$form = new Form(new Controller(), 'FormStub', new FieldList(), new FieldList());
/** @var CMSPageAddController $addController */
$addController = singleton('CMSPageAddController');
$addController->doAdd($data, $form);
// Pull the newly created page ID from URL in the location header. This is better than relying on global state to be
// modified (i.e. looking instead at $editController->currentPageID() which is initialized inside of ->doAdd()).
$response = $addController->getResponse();
$headers = $response->getHeaders();
if (isset($headers['Location'])) {
// ... magic ✨
} |
Oh, and I forgot -- to tie it all together, I've also got a if ($hasDelete && !$obj->canHardDelete()) {
user_error("Warning: Using a GridFieldConfig_VersionedRecordEditor with a versioned SiteTree object will " .
"allow deletion of an object which will cause it to be orphaned in published mode but potentially unable to " .
"be accessible in CMS (if it's not visible in the CMS left-hand site tree). Please be sure to enable " .
"->hard_delete = true on these objects.", E_USER_WARNING);
} |
👆 Key point there is that deleting a versioned Sorry for being scatterbrained, I'm busy but had a lot to say and haven't organized my thoughts 😭 Let me know what you think about maybe integrating those features into either of these repositories or potentially merging them or even both. |
Hi, it looks like the functionality for this class
GridFieldPage
isn't super complicated and really just provides some methods that extend the useful grid-capable functionality. In my case, I have a pretty complicated class hierarchy in my site and, relatively deep in that hierarchy I have a one-off situation where a certain page type needs to be able to be displayed inside of aGridField
. In my case, it doesn't make sense to affect 90% of the pages on my site in order to apply a few methods, so I got to thinking...I propose either converting this to an extension (less likely) or better, adding an extension to this code base and then sharing functionality between classes via traits (easily accomplished with good compatibility via direct includes as SilverStripe 3.x apparently still has issues with autoloading traits 🤕).
I think I'll submit a PR with an example of this change. In the meantime, I'll have a custom version of this in my code base which is just a copy of this code applied as an extension.
The text was updated successfully, but these errors were encountered: