SilverStripe 4 Compatibility

[UndefinedOffset]

• Create 1.0.x branch
• Tag 1.0.0
• Alias master as 2.0.x
• Merge Minor: Code formatting #102 into master
• Migrate to namespaces
• Migrate JavaScript from jQuery.entwine to the new JS API
• Migrate stylesheet to compass
• Switch to Vendor Module
• Improve styles
• Tag 2.0.0-alpha1

[zanderwar]

WIP #106 - Will require assistance with JS

[mizuber]

Do you have already plans when to finish with the SS4 compatibility?

[UndefinedOffset]

It's a matter of time for me unfortunately, I'd like to get the JS migrated before I tag a 2.0.0-alpha1. But if someone can confirm the legacy js is working I'll tag a 2.0.0-alpha1. It's very possible I may not get back to this until work switches to 4.0 development closer or after release :(

[zanderwar]

Legacy JS appears to be fine. Entwine has only been deprecated, not removed IIRC

[UndefinedOffset]

Interesting... jQuery UI is still loaded too? If it is that's surprising, I figured it would have been removed since they're not using it. I guess they need it to be still loaded for compatibility. Assuming it's working, I'll tag a 2.0.0-alpha1.

I really do need to find some time with SilverStripe 4.

[zanderwar]

The CSS is the only thing that needs some love from what I discovered during my time updating it to SS4.

Drag & drop functionality was working as expected, I didn't thoroughly test it though. I just got the tests passing and ensured you could sort in the CMS

[UndefinedOffset]

Ok, I've tagged alpha1. I'll do the rest of the work here in the coming weeks hopefully.

[sminnee]

How's this going? I see that master is your SS3 version and you have a separate branch for SS1. Your SS3 version also has the wrong version constraint.

[zanderwar]

2.0.x is 4.0, WIP though still I believe

[UndefinedOffset]

@sminnie 2.0x branch is working in 4 and looks ok, master is 3.x compatible still. I should adjust the version constraint to ~3.0, that experimential branch is old and busted... Probably should delete it :S.

[UndefinedOffset]

I've tagged a 0.6.10 and adjusted master to constrain to less than 4.0.0 which should help with some of the composer confusion. I'll double check on 4.0.0 beta and make sure that it's still working there, if it is (which I expect it to be) then I'll take a 2.0.0 beta1. I'm probably going to table the JS and Compass changes until later when I've had a chance to experiment more with the new API's in 4.0.

[guyvanbael]

the code example in the docs are not working.
Nothing is showing up. Even the checkbox is not visible
addComponent is not working anymore in SS4
this what i have so far..
`
$config = GridFieldConfig_RecordEditor::create();
$items = $config->getComponentByType('SilverStripe\Forms\GridField\GridFieldPaginator');
$items->setItemsPerPage(2);
$sorting = $config->getComponentByType('sortablegridfield\src\Forms\GridFieldSortableRows');

	$grid->setConfig($config);`

[UndefinedOffset]

Are you using the 2.0.0 branch or a 2.0.0-alpha tag? I just tried on my local version of 4.0.0-beta3 and it's working as expected.

[guyvanbael]

i installed 2.0.x on the beta 3 version

[UndefinedOffset]

Have you run dev/build?flush=1. As well are there any errors in your browser's JavaScript console or any PHP errors?

[guyvanbael]

yes i did. No errors. Code in the docs is legacy code i think. The pagination i added using getcomponentbytype is working. Don't know how to do that for setting the sorting column

[UndefinedOffset]

Can you post your composer.json as well as the code around where you are initializing your GridField?

[guyvanbael]

this is the composer.json

{
"name": "silverstripe/installer",
"type": "silverstripe-recipe",
"description": "The SilverStripe Framework Installer",
"require": {
"php": ">=5.6.0",
"silverstripe/recipe-plugin": ">=0.1@dev <1.0",
"silverstripe/recipe-cms": "1.0.0-beta3",
"silverstripe-themes/simple": "~3.2.0",
"silverstripe/googlesitemaps": "dev-master",
"undefinedoffset/sortablegridfield":"2.0.x"
},
"require-dev": {
"phpunit/PHPUnit": "^5.7"
},
"extra": {
"branch-alias": {
"4.x-dev": "4.0.x-dev",
"dev-master": "5.x-dev"
},
"project-files-installed": [
".htaccess",
"mysite/.htaccess",
"mysite/_config.php",
"mysite/_config/mysite.yml",
"mysite/code/Page.php",
"mysite/code/PageController.php",
"web.config"
]
},
"config": {
"process-timeout": 600
},
"prefer-stable": true,
"minimum-stability": "dev"
}

[guyvanbael]

this is my getcms...

public function getCMSFields() {
	$fields = parent::getCMSFields();
	
	$fields->addFieldToTab('Root.guy', new HTMLEditorField("MyShortText","tekstje"));
	$fields->addFieldToTab('Root.guy',new UploadField('Avatar','foto'));
	$fields->addFieldToTab('Root.guy', $grid = new GridField('Producten', 'Producten', $this->Producten()->sort('Sort','asc')));
	$fields->addFieldsToTab('Root.Main', array(
		TextField::create('MyShortText','Korte Tekst'),
		DateField::create('MyDate','Datum'),
		textfield::create('AnotherText', 'nog een tekst'),
		TreeDropdownField::create("RelatedpageID", "Choose a page to show on the right:", "Page")
	),'Content');

	$config = GridFieldConfig_RecordEditor::create();
	$items = $config->getComponentByType('SilverStripe\Forms\GridField\GridFieldPaginator');
	$items->setItemsPerPage(2);
	$sorting = $config->getComponentByType('sortablegridfield\src\Forms\GridFieldSortableRows');

	
	$grid->setConfig($config);


	return $fields;
}

[UndefinedOffset]

You need to add the component to your GridField it is not added automatically (per-documentation) and ensure you are including the namespace in your used namespaces. I've updated the docs and examples regarding the namespaces.

use UndefinedOffset\SortableGridField\Forms\GridFieldSortableRows; //Namespaces should be added to the top of your file

public function getCMSFields() {
	$fields = parent::getCMSFields();
	
	$fields->addFieldToTab('Root.guy', new HTMLEditorField("MyShortText","tekstje"));
	$fields->addFieldToTab('Root.guy',new UploadField('Avatar','foto'));
	$fields->addFieldToTab('Root.guy', $grid = new GridField('Producten', 'Producten', $this->Producten()->sort('Sort','asc')));
	$fields->addFieldsToTab('Root.Main', array(
		TextField::create('MyShortText','Korte Tekst'),
		DateField::create('MyDate','Datum'),
		textfield::create('AnotherText', 'nog een tekst'),
		TreeDropdownField::create("RelatedpageID", "Choose a page to show on the right:", "Page")
	),'Content');

	$config = GridFieldConfig_RecordEditor::create();
	$items = $config->getComponentByType('SilverStripe\Forms\GridField\GridFieldPaginator');
	$items->setItemsPerPage(2);
	$config->addComponent($sorting=new GridFieldSortableRows('SortOrder'));

	
	$grid->setConfig($config);


	return $fields;
}
``

[guyvanbael]

that does the trick! Thanx @UndefinedOffset !

[zanderwar]

Why was the type: silverstripe-vendormodule reverted out of curiousity?

[UndefinedOffset]

Noticed it was going to be a bit of a pain to dev (mainly new) modules on, you pretty much have to use composer from the start. Or if your on Windows learn the commands for ntf's equivalent to symlinks. Of course unless I'm missing something ;) and if I am it probably should be something in the docs for 4.

[zanderwar]

You're obviously referring to the loss of highlighting/autocomplete? I have the same issue, but still should make the sacrifice to keep it out of docroot imho, SS are urging all new modules to adopt vendormodule albeit not required

[UndefinedOffset]

Actually no, I was referring to exposing assets such as CSS, js or images. Vendor by default is blocked by htaccess in a base install. Exposing it won't work because requirements will still look for it to be in the resources folder. Having hard copies there that you move back into the checked out module while it would work would be messy to say the least.

[zanderwar]

Maybe @sminnee has some insight

[sminnee]

@UndefinedOffset our recommendation is that all modules for SS4 get changed to vendormodule. By the time SS5 comes around we'd probably drop support for not putting them in vendor.

The vendor-plugin copies the static assets out, either by symlink or by copy, depending on environment config.

SilverStripe 4 doesn't really support not using composer.

[sminnee]

It sounds like we'll need to improve the use-case of developing modules on Windows, if symlink doesn't work there?

[sminnee]

SS 4.1 will, by default, move the webroot to a public/ subfolder or similar, so this problem will affect all silverstripe-module as well as silverstripe-vendormodule

[UndefinedOffset]

Wouldn't that make it a bit of a pain with new modules? Since often they are not available to composer right away?

As for Windows and symlinks it doesn't per-say but the vendor plugin does support the ntfs equivilent but for new modules exposing them with the plugin doesn't seem easily possible?

[sminnee]

Perhaps the composer vendor-plugin should have a way of explicitly triggering it on an arbitrary folder?

[zanderwar]

Since often they are not available to composer right away?

All repos should ideally have a composer.json, ideally anyway. It's normally the first thing I write before creating the code folder

[zanderwar]

@sminnee maybe a YML file in _config as a fallback ?

[sminnee]

OK I've raised this ticket about the underlying issue: silverstripe/vendor-plugin#7

Although I agree that we have to sort out the edge-cases, trying to avoid this problem (by not using silverstripe-vendormodule) is likely to be a losing battle. It would be better to identify and resolve any remaining problems caused by moving module out of the directly-web-accessible path.

[UndefinedOffset]

For sure I agree I'll move it back to one, I do agree having an easy way to trigger vendor plugin to do it arbitrarily by scanning a composer.json would definitely help.

[UndefinedOffset]

I'm going to tag a 2.0.0 stable shortly, I've deferred the JS changes to #109. As for moving the css over to compass there's not really much to it anyways and it's just another layer of abstraction for simple styles.