Upgrade to bootstrap 4 - Githubissues

schmunk42 commented 6 years ago

maintain extensions that depend on bootstrap will become a nightmare (you need to support 2 lines even if the only difference is used yii2-bootstrap extension).

Using extensions will become a nightmare if it is in the same namespace, if one is requiring 2.0.* and another 2.1.* it'll be impossible to update.

The use-cases mentioned by @Insolita are very common and important. In contradiction to "normal" PHP libs, this one could exists multiple times, since it's (almost) only a wrapper for an asset package.

Enrica-r commented 6 years ago

I have anticipated the upcoming issue what you discussed few posts again. Look back to my post of 16th April 2017 already. At this date the time wasn't mature for such a discussion because all developed with BS3 and was simple to fork a separate GIT version.

I support the concern that not all extensions using BS3 (like Kartik's) change at the same shot. Also it's almost impossible to change a larger application in one release. Yii2 risks that 2.0.x release will be used for long term.

So I proposed to install a B3 extension (marked as depreciated) parallel to BS4 extension. In release 2.1 Yii2 should ensure that "old" extensions work as usual with BS3. After with release 2.1 all extension developers should get time to migrate their extensions to BS4. If they want they could support parallel installation also. Yii2 should deliver a function which lists the installed BS versions and which BS version is default. With release 2.1.x BS4 should be default and with 2.x.0 BS3 will be removed.

I know that such a migration/versioning concept will produce a lot of work but it can use for future BS or Jquery versions.

@samdark : I don't what the correct way is. I don't want criticize Yii2 developer as it seems sometimes. I thank for your engagement. Please check my proposal of 16/04/2018 to avoid the "nightmare".

rob006 commented 6 years ago

@Insolita I've migrated yii1 app from bootstrap2 to bootstrap3:

for backend it was relatively simple (few hours of work), since most of work was done by php-wrappers,
for frontend impact of used php-wrapper was irrelevant due to many bootstrap customizations.

If I will need to use separate package with different namespace it will be much harder for me.

@schmunk42

Using extensions will become a nightmare if it is in the same namespace, if one is requiring 2.0. and another 2.1. it'll be impossible to update.

Releasing separate package for bootstrap4 will not save you this nightmare. There are over 1k extensions that depend on this package - all of them should have a clone for bootstrap4, so you could use the same extension for two different versions of bootstrap in a single app. It's unrealistic, a separate package will only increase fragmentation (it will be harder to maintain extension for two different versions of bootstrap).

schmunk42 commented 6 years ago

all of them should have a clone for bootstrap4, so you could use the same extension for two different versions of bootstrap in a single app.

Sorry to say that, but that's wishful thinking - it should be that way, but it's not going to happen very fast and smoothly. By using the same repo we'd just pretend it would be easy, but it's making things much worse.

Here's a list of our current dependencies to yii2-bootstrap:

root@714a18efd4d3:/app# composer depends yiisoft/yii2-bootstrap
2amigos/yii2-selectize-widget     1.1.0   requires  yiisoft/yii2-bootstrap (~2.0.0)  
dektrium/yii2-user                0.9.13  requires  yiisoft/yii2-bootstrap (^2.0.0)  
dmstr/yii2-adminlte-asset         2.6.0   requires  yiisoft/yii2-bootstrap (~2.0.0)  
dmstr/yii2-bootstrap              0.2.1   requires  yiisoft/yii2-bootstrap (^2.0.6)  
dmstr/yii2-cookie-button          0.2.0   requires  yiisoft/yii2-bootstrap (*)       
kartik-v/yii2-krajee-base         v1.8.9  requires  yiisoft/yii2-bootstrap (@dev)    
lajax/yii2-translate-manager      1.7.1   requires  yiisoft/yii2-bootstrap (*)       
dmstr/phd5-app                    -       requires  yiisoft/yii2-bootstrap (2.*)     
yiisoft/yii2-apidoc               2.1.0   requires  yiisoft/yii2-bootstrap (~2.0.0)  
yiisoft/yii2-debug                2.0.13  requires  yiisoft/yii2-bootstrap (~2.0.0)  
yiisoft/yii2-gii                  2.0.6   requires  yiisoft/yii2-bootstrap (~2.0.0)  
zhuravljov/yii2-datetime-widgets  1.1.2   requires  yiisoft/yii2-bootstrap (~2.0.0)

Just take yii2-apidoc as an example, I might just want to create docs with BS3, but the rest of my app will use BS4 (even if I'd have to fork 5 repos for that). How would I do this? I can not install two versions of the same extension, even if this is a dev-dependency.

Instead, as mentioned before, when upgrading from BS3 to BS4 in an extension or app, I'd change

use yii\bootstrap\Collapse;

into

use yii\bootstrap4\Collapse;

bobonov commented 6 years ago

Something to consider in having 2 separate repos. Scenario: You start using porting BS4, you correct all your namespace to point to BS4. You don't correct vendors namespace and fix the extensions to use BS4 classes. Therefore if you use 3rd party extension that still use bootstrap this will lead to a big mess since BS3 and BS4 are loaded at same time overriding each other in term of css rule and probably causing js conflict to each other.

So porting to BS4 is not just matter of changing namespace, it is a app wide work. You can operate per single view, having one view all BS4 while another is still BS3 but think at the result, you will have 2 pages that look differently, maybe slightly but different. So if you port to BS4 you can't go in production till you finish

While some yii2 extension should work out of the box just by using newer version of yii2-bootstrap some other depends on a third party extension to be ported first (ie select2)

But the issue about front/back is true, single repository do not allow to work on them separately.

In this case I would reconfigure yii2 to use 2 separate composer.json/vendors for front and back. Something like frontend/vendors frontend/composer.json I know this is not ideal and nice but this would allow to keep separated the old AdminLTE BS3 backend from the new shining BS4 frontend without accidents.

rob006 commented 6 years ago

By using the same repo we'd just pretend it would be easy, but it's making things much worse.

By using separate repo we'd just pretend that you could simply use bs3 i bs4 simultaneously, but this is far more complicated.

How would I do this?

You don't need to add yii2-apidoc to dependencies in the first place, you could install it separately. ;)

Anyway, both solutions are bad. Instead arguing which is worse we could try to create one extension compatible with both versions of bootstrap with switch like Bootstrap::setVersion(Bootstrap::V4)) which changes output generated by helpers/widgets.

schmunk42 commented 6 years ago

By using separate repo we'd just pretend that you could simply use bs3 i bs4 simultaneously, but this is far more complicated.

The use-case is not to use them on the same page/layout, but having a backend modules in BS3 and a frontend in BS4 will be a very common thing. If this is not possible, It's like restricting the application just to use one "theme".

Instead arguing which is worse we could try to create one extension compatible with both versions of bootstrap with switch like Bootstrap::setVersion(Bootstrap::V4)) which changes output generated by helpers/widgets.

It won't result in cleaner code, if one extension could support both versions simultaneously.

Enrica-r commented 6 years ago

In my opinion the Yii team has to avoid a hard break analogue Yii1 to Yii2 caused by BS version change. Unfortunately Yii depends on BS in most extension. I aggree with @schmunk42 to have a clean code but the Yii team should ensure a coordinated migration from BS3 to BS4 (incl. JS).

As written in other posts BS3 and BS4 can't be mixed on one page (layout) but it could be mixed in an application with two layouts (eg. frontend vs backend).

In my opinion there should be clear migration phases defined by Yii and this must be obligatory for all extension developers otherwise an extension will loose its Yii2 2.1.x compatibility. My proposal is to have four phases: (@samdark )

Yii2 prepares a release which supports two repos as mentioned before (another namespace) plus a method in 'Yii::$app' which delivers BS version loaded in current layout's asset bundle. Yii team publishes migration instructions with examples to extension developers and app developers. A published roadmap for developers is obligatoy also.
Extension developers get 3 to 6 months time to adapt their BS dependent extensions. They have to document the compatibility and how it works. They could have to alternatives to do this: a) Maintain two forks distinguished by namespace. Adv: clear code, clear decomm / Disadv: maintain to branches parallel for a certain time. b) Support both BS version in one code. The extension asks 'Yii::$app->bsVerison' and reacts concerning the version. Adv: one namespace, no parallel packages to maintain, easier for app developers / Disadv: Makes code more complicated, needs a cleanup release later for each extension.
After 6 months (hopefully all extensions will have been adapted) app developers adapt their applications. If they do all work in one relase or if they migrate FE/BE separately or if they change some areas is their decision. This phase could have a period of 1 - 2 years.
After phase 3 Yii team announces a definitive decommision of BS3 support. The package 'yii-bootstrap" will be removed and also extension developers are allowed to remove their packages or cleanup theirs codes from BS3 part.

Probably Boostrap will develope version 5 already in this time and the process will start again. Same procedures could be used for Jquery upgrades. @samdark : Please discuss with your core team, how Yii could support BS version change (also for their own extension).

bobonov commented 6 years ago

As written in other posts BS3 and BS4 can't be mixed on one page (layout) but it could be mixed in an application with two layouts (eg. frontend vs backend).

I think most of the people misunderstood my issue about mixing BS3 and BS4 in same view, bad on me and on my English.

Some extension will work out of the box since they will inherit their bootstrap code directly from yii2-bootstrap. Some other uses tags and classes directly and need to be migrated first. Some other extension relay on third party code to be migrated first, ie any yii2-select2 widget

I think that we all agree that (beside the yii2-boostrap solution will be) my migration can't finish till all the extension I use get migrated.

yii2-bootstrap new version VS yii2-bootstrap and yii2-bootstrap4 Many point are have already been exposed in the discussion, my concern about yii2-bootstrap and yii2-bootstrap4 is that would be more difficult to do a work in progress migration.

What I mean. I use Select2 in my project. Probably I use it in many forms and in many search forms. I start migration so I replace yii2-bootstrap with yii2-bootstrap4 in composer. But yii2-bootstrap is not removed since my third party yii2-selec2 widget require it. So I obtain that BS3 and BS4 get mixed and every page that use the select2 widget stop loading properly and probably is not usable at all. On the other way with yii2-bootstrap version bumping maybe my Select2 looks weird or in the worst case is not working but my page should load and I can work on porting the rest of the elements while waiting for a new Select2 release which support bootstrap. In this way the work can go in parallel with yii2 widget fixing and I do not have to wait. Cons it that you need to use separate composer (in the worst case one for each application you have)

schmunk42 commented 6 years ago

But yii2-bootstrap is not removed since my third party yii2-selec2 widget require it. So I obtain that BS3 and BS4 get mixed and every page that use the select2 widget stop loading properly and probably is not usable at all.

That's true and it's an issue. AssetBundle::conflicts comes to my mind to handle that, but it's just an idea.

What's a bigger issue is, that if you want to install ie. a newer version of gii which depends on BS4, you won't be able to do that if just one single input widget in your application requires BS3.

schmunk42 commented 6 years ago

I need to reference https://github.com/yiisoft/yii2-bootstrap/pull/212 here, it's about removing bower dependencies completely and not managing assets like JS/CSS with composer.

IMHO this should be a goal for the next release, since the framework core in 2.1 won't include bower-packages anymore. Removing those dependencies in composer.json might also help those who are planning to install different BS versions for different layouts, since there won't be any conflicts - now it's the time for some bigger changes 😄

JQL commented 6 years ago

Opening a can of worms here but, why should "Yii" be dependant on any CSS framework?

Wouldn't it be better in the long run to move the CSS frameworks into libraries and the user decides which framework to use? With a system default if none is chosen.

OK, I know there's more than a ton of work into setting up the libraries and the code to call the correct libraries.

My 2¢

jacmoe commented 6 years ago

It's not dependent on any CSS framework :)

That said, yes: some features of Yii - debug interface - depends on Bootstrap. To make life easier, the Yii team decided on Bootstrap instead of rolling their own.

I tend to not use any Bootstrap related Yii functionality, though.

JQL commented 6 years ago

When you look at the code for the Widgets, Tables etc. they include BootStrap3 mark up:

/**

@var array the HTML attributes for the container tag of this widget. The tag option specifies

what container tag should be used. It defaults to table if not set.

@see \yii\helpers\Html::renderTagAttributes() for details on how attributes are being rendered. */ public $options = ['class' => 'table table-striped table-bordered detail-view'];

Why not have a system to translate table into say "display:grid" based of whether the user wants CSSGrid or BootstrapX or some other framework? That's what I'm suggesting...

Yes, I know they are different, very different but, I think you understand what I'm getting at.

jacmoe commented 6 years ago

If you don't set the options, default values are assigned.

2018-02-10 21:55 GMT+01:00 John Lavelle notifications@github.com:

When you look at the code for the Widgets, Tables etc. they include BootStrap3 mark up:

/**

@var https://github.com/var array the HTML attributes for the container tag of this widget. The tag option specifies

what container tag should be used. It defaults to table if not set.

@see https://github.com/see \yii\helpers\Html::renderTagAttributes() for details on how attributes are being rendered. */ public $options = ['class' => 'table table-striped table-bordered detail-view'];

Why not have a system to translate table into say "display:grid" based of whether the user wants CSSGrid or BootstrapX or some other framework?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/yiisoft/yii2-bootstrap/issues/77#issuecomment-364691324, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFNsGvSIIKAN3kF7hBRYgxRaYzqELNvks5tTgJTgaJpZM4Fu7cX .

schmunk42 commented 6 years ago

I talked to @cebe a while ago about this.

My suggestion would be to create a new repo ie. yii2-bootstrap4 which is only compatible with 2.1; including new asset management and Bootstrap 4.

You can still decide if this repo should support BS4 in a later version, but now it looks rather tied to BS3 (see https://github.com/yiisoft/yii2-bootstrap/issues/221#issuecomment-365178860)

fcaldarelli commented 6 years ago

I'm agree with @schmunk42 because developers should be able to decide if upgrade to bootstrap 4 or keep version 3. I have too much projects based on bootstrap 3, so if I had to upgrade every single project this would be a lot of work.

fcaldarelli commented 6 years ago

The matter of making a soft transition from bootstrap 3 and bootstrap 4 is very important.

This could be a possible approach.

Bootstrap 3 should not be updated frequently anymore, so we could package the bs3 sources statically inside in a yii2-bootstrap3 package, that we should update everytime there is an update of version 3 (I think not frequently).

This is needed because bootstrap composer package "twbs/bootstrap" now points to version 4.

Then we have to create a yii2-bootstrap4 package that contains a dependency to "twbs/bootstrap", so it will install last bootstrap version 4.

The yii2-bootstrap3 package will expose a Boostrap3Asset, and the package yii2-bootstrap4 will expose a Bootstrap4Asset.

In this way will avoid conflict between two different version of bootstrap.

When twitter will release bs5 and the "twbs/bootstrap" will point to bs5 instead bs4, we should only put statics bs4 sources inside yii2-bootstrap4 package and create a new yii2-bootstrap5 that will point to same repository "twbs/bootstrap" (if it will not change), and so on.

The developers will can decide what bs version to use, without creating panic, because they can specify AppAsset dependencies (Boostrap3Asset or Bootstrap4Asset).

This will allow to have inside the same website pages using bs3 and pages using bs4, making easy the transition between these version, sing 2 layouts, the first pointing to bs3 and the last pointing to bs4.

fcaldarelli commented 6 years ago

To demonstrate previous post, I've create 2 extensions:

https://github.com/FabrizioCaldarelli/yii2-bootstrap3 that contains bs3 source code inside and provides Bootstrap3Asset.php;
https://github.com/FabrizioCaldarelli/yii2-bootstrap4 that requires twbs/bootstrap package and provides Bootstrap4Asset.php;

Then I removed references to Bootstrap3 to yii2-bootstrap extension: https://github.com/FabrizioCaldarelli/yii2-bootstrap/commit/3de2226520f9198feed11b8c2a1fda313bed4009

This is needed becase It would call always bootstrap 3 assets files, even if we have requested Bootstrap4Asset in layout file (making bs library conflicts). I have kept these files to avoid to delete these references in every file in which yii\bootstrap package is used.

Similar at this, we can change in yii2-gii references to bootstrap3 specifying, for example:

'sfmobile\bootstrap4\Bootstrap4Asset' or 'sfmobile\bootstrap3\Bootstrap3Asset' instead 'yii\bootstrap\BootstrapAsset' at https://github.com/yiisoft/yii2-gii/blob/master/src/GiiAsset.php#L29

Finally I've create a fork from yii2-basic-app with these changes:

Added two layouts : main-bs3.php, main-bs4.php, that apply respectively Bootstrap3Asset and Bootstrap4Asset;
Added a site/test-bs4 action to show how same controller can use different bootstrap versions (bs4 in this case);

https://github.com/FabrizioCaldarelli/yii2-app-basic-bs/commit/3b7f7fb37d6c66cc407f0d902d1bb5699ae9f930

So we can handle bs3, bs4 and next bs versions without breaking code and headache.

Enrica-r commented 6 years ago

@FabrizioCaldarelli Thank you for your good work an your concept. Your idea with two Layouts 'main-bs3.php' amd 'main-bs4.php' you can decide for each page which boostrap version will be loaded. So far ok.

In a further step depending widgets (extension) should be adapted also. As a developer of such widgets we have two possibilities:

first: The view (layout) or Yii's app has a property which tells my wigets which version of BS (or better CSS framework) is loaded so that the widget can put out different code Syntax or it produces an error like 'this Framework isn't suported'
second: For each widget package exists a bs3 version as a b4 version also (similar than your packages).

Using the version tags like 'Yii-bootstrap' does ends up in a problem. Version 2.0.x suports bs3 only, version 2.1.x suports bs4 only but version 2.2.x bs3 only again. This is confusing and the maintenance effort is unacceptable. With proposal one 'Yii-boostrap' could provide in version 2.2.x b3 and b4 compatibility.

I prefer alternative 1 but then you package should deliver a framework Name like 'bootstrap-3' accessible for widgets.

Your work should be part of Yii's bootstrap package. Coordinated for all developers.

fcaldarelli commented 6 years ago

@Enrica-r From widgets point of view, I also agree with your first proposal.

We could add a "uiFramework" property to View class, so the layout used could specify what ui-framework has used. This could be useful even if we want to use other ui framework (semantic ui, etc..) and the widget would adapt to it.

What do you think?

Enrica-r commented 6 years ago

@FabrizioCaldarelli : That's exactly my alternative no. 1 and also what I wrote on 22 and 23 Jan. this year.

This property shouldn't be in your package. It should be in Yii's core. If you look back to Yii2's history this wasn't an issue because BS3 was almost part of Yii fully implemented. Slowly the strategy changed and Yii core moved all ui elements in separate packages so that Yii core is independent of any css framework. Theoretically it should work with ZURB foundation.

If your ui property is part of yii's core all widget developers can check which css framework is loaded with the layout. So they can react with an error message or they can deliver translation class. (proposal of @JQL ).

@samdark Could you analyze @FabrizioCaldarelli 's solution? If it's a way then merge it to version 2.1.x and merge functionality of 'Yii-bootstrap' version 2.1 and 2.2 while using view's 'uiFramework' property. This seems to be the only way to avoid a 2.1.x and 2.2.x fork for longer duration.

fcaldarelli commented 6 years ago

@samdark @Enrica-r Also this solution will allow to use different UI Framework. It is only requested to widgets developer to handle these framework, with little differences inside the same widget source code.

Enrica-r commented 6 years ago

@FabrizioCaldarelli Exactly what I think and what I discussed during BS4 alpha phase, but nobody was aware of it. Now it comes up.

schmunk42 commented 6 years ago

We could add a "uiFramework" property to View class, so the layout used could specify what ui-framework has used. This could be useful even if we want to use other ui framework (semantic ui, etc..) and the widget would adapt to it.

I don't think this is a viable solution, I will just lead to a mess in widget code.

fcaldarelli commented 6 years ago

@schmunk Alternatives to allow widgets developers to handle different ui framework without creating many package of same source one (one for ui framework)?

And remain to solve question about switching bs3 to bs4

schmunk42 commented 6 years ago

Alternatives to allow widgets developers to handle different ui framework without creating many package of same source one (one for ui framework)?

None. PHP packages (or asset packages via composer) can only be installed in one version, but technically there's no reason for not installing twbs/bootstrap in 3.x and 4.x.

fcaldarelli commented 6 years ago

@schmunk I think that you, as all of us, have a lot of projects based on Yii 2.0 and bs3. How do you plan to switch to Yii 2.1 without updating all views of all projects at same time?

schmunk42 commented 6 years ago

In our case I'd plan to continue using yii2-bootstrap (BS3) for the backend (AdminLTE). And BS4 in the frontend via yii2-bootstrap4 (if there'll be a package for it :))

I actually don't have the illusion that this can be done automatically.

fcaldarelli commented 6 years ago

@schmunk bs4 for new frontend projects. What about existings? What about using other ui framework (or eventually no ui framework)? All widgets are heavily linked to bs4 and yii does not offer convenient way to manage switching from an ui fw to another.

schmunk42 commented 6 years ago

bs4 for new frontend projects. What about existings?

I think switching involves some amont of manual work. For BS3 to BS4 I'd change the widget namespace from yii\bootstrap to yii\bootstrap4.

What about using other ui framework (or eventually no ui framework)? All widgets are heavily linked to bs4 and yii does not offer convenient way to manage switching from an ui fw to another.

You gave the answer already :) Widgets are heavily linked to the CSS (and sometimes JS) framework. There's no easy way to switch between them, just by setting a property.

For example, I just picked this one randomly https://github.com/nonzod/yii2-foundation - some widgets are the same, some are only available for Zurb some others only for Bootstrap.

While it would be great if we could switch CSS framework so easily, I simply think it creates more work than doing a clean switch. I once tried this when we switched from blueprint to bootstrap six years ago, it was just not feasible.

Enrica-r commented 6 years ago

@schmunk42 You are worry about a mess within widget code. I say yes and no because it depends how complex a widget is. For simple widgets which uses some BS CSS classes it's easier to build in a "library" class which delivers BS3 or BS4 classnames depending on which framework is loaded in main layout (recognizable via a property in the view class). You save time to maintain several packages.

For more complex widgets using different Jquery versions it could be easier to handle separate repositories which are addressed by name space. The widget init method should verify framework version and throw an error if BS3 is loaded if BS4 is expected.

Fabrizios method allows to have eg. backend on BS3 and frontend on BS4 or it allows to do stepwise migration within a project. But it's not possible before extension developers haven't adapted their widgets (eg. Yii-Bootstrap or Kartik's active form).

schmunk42 commented 6 years ago

allows to do stepwise migration within a project.

My point is, that you shouldn't do a "stepwise" migration of a CSS framework, because it will mess things up - just use one CSS framework per layout. And this is also possible when having two extensions, but in a much cleaner way.

Enrica-r commented 6 years ago

@schmunk42 That's clear and I fully agree with you. One layout (eg. main-b3.php) can have only one css / js framework. But another newer part of your project can use (eg. main-b4.php). If the widget code can recognize this you don't have to do anything (concerning this widget). Otherwise change name space pointing to an adapted version.

Enrica-r commented 6 years ago

@schmunk42 After a parallel migration phase (defined by Yii project) all extension developers could remove old BS3 packages or code libraries. If Yii is producing a hard break BS3->BS4 old versions will survive too long.

fcaldarelli commented 6 years ago

@schmunk This is not only a stepwise matter, but there are many widgets (Kartik select, date picker, etc..) that they are not immediately available on bs4. And when Kartik will update them, it could point directly to Yii-bootstrap4, messing up where we use bs3. I think that we should give a guideline to handle these switches, because they could happen frequently.

schmunk42 commented 6 years ago

all extension developers could remove old BS3 packages or code libraries

Why should someone remove BS3 code? There's absolutely nothing wrong with it. Moreover, there's no central authority which can force any developer to do something.

And when Kartik will update them, it could point directly to Yii-bootstrap4, messing up where we use bs3. I think that we should give a guideline to handle these switches, because they could happen frequently.

The guidance is: Also create a new extension or do a major release - anything else is a bug. Btw: the former one would allow you to use those extensions with BS3 and/or BS4, while a major version upgrade would force you to use a specifc BS version.

Enrica-r commented 6 years ago

@schmunk42

Why should someone remove BS3 code? There's absolutely nothing wrong with it. Moreover, there's no central authority which can force any developer to do something.

I don't agree with this. All software provider terminate their support for certain als versions. If I were Kartik I would support BS3 packages or compatibility for two or three years. Another developer migrates his project and doesn't provide both mainstream versions parallel. What a mess!

That's why I proposed that Yii team defines a migration phase during wich all providers of extensions have to maintain BS3 and BS4. If you want to use BS3 for longer period after the "official" migration phase you will have to fork the extension.

schmunk42 commented 6 years ago

I don't agree with this. All software provider terminate their support for certain als versions.

For me removing code and dropping support are two different things.

If I were Kartik I would support BS3 packages or compatibility for two or three years. Another developer migrates his project and doesn't provide both mainstream versions parallel. What a mess!

Thinking about this, it's one more reason to create a separate extension. We should not even start having properties in the views, triggering "magic" changes of widgets markup. Followed by the requirement that all widgets would have to be updated to support such a change.

all providers of extensions have to maintain BS3 and BS4.

I don't want to annoy people by repeating myself, but this is simply not possible.

@samdark My position on this became more clear after the recent discussions:

Close this issue as wontfix and create a new repo yii2-bootstrap4 - and add a migration guideline to 2.1 that extension developers should do the same.

samdark commented 6 years ago

Yes. Makes sense.

fcaldarelli commented 6 years ago

@schmunk will yii2-bootstrap continue to pointing to twbs/bootstrap repository (locked to major version 3) or will it contain bootstrap source code inside? Because if both yii2-bootstrap and yii2-bootstrap4 will point to bootstrap repository, there will be a conflict with file names, because bootstrap has maintained same vendor /vendor/twbs/bootstrap path.

schmunk42 commented 6 years ago

will yii2-bootstrap continue to pointing to twbs/bootstrap repository (locked to major version 3)

I'd leave it pointing to bower/boostrap (v3).

yii2-bootstrap4 will load its sources from npm. Depending on the way of the installation you can have multiple versions (foxy+npm) or just one (asset-packagist).

kartik-v commented 6 years ago

Was led to this issue from another one (and see some feedback on few of my BS based extensions). Feel it makes sense to have a separate Yii2 extension for BS3 and a separate one for BS4.

Reasons being that BS4:

includes significant changes to HTML markup for many critical components and way widgets will need to be rendered
includes changes to JS/JQuery dependencies
includes changes to icon framework dependencies (e.g. no glyphicons bundled and most default icons will change)
as well as changes to basic default CSS look and feel (e.g. flex layouts, font family, font size, line heights, obsoleting of basic CSS classes like pull-right, btn-xs etc.)

In this scenario all BOOTSTRAP based Yii2 extensions need appropriate dependencies to run both for BS3 and BS4 based on the situation and choice of the developer.

If it were to be maintained as a single extension --- my suggestions/recommendations would be:

maybe create yii2-bootstrap extension as a module and have a bsVersion property set for module (or as a property in the widget) that can be referred by all widgets
relevant Bootstrap3Asset or Bootstrap4Asset bundle can get registered on widget init based on above

samdark commented 6 years ago

Considering all the feedback, I think it makes sense to have yii2-bootstrap4 separately.

alexantr commented 6 years ago

Yes! BS3 & BS4 like Yii 1.1 & Yii 2 - too different

samdark commented 6 years ago

https://github.com/yiisoft/yii2-bootstrap4

samdark commented 6 years ago

Need to move 2.1 branch there.

schmunk42 commented 6 years ago

btw: regarding https://github.com/yiisoft/yii2/issues/15983

It could (should) be released as yiisoft/yii2-bootstrap4 version 1.0.0

kartik-v commented 6 years ago

Need to move 2.1 branch there.

👍 Great... maybe the namespace in composer.json and classes needs to be changed to bootstrap4 as well... so that classes can be referred something like yii\bootstrap4\Modal for example.

EDIT:

Created Pull Request # 3

samdark commented 6 years ago

We're going to finally agree on global versioning policy soon. Not closing the issue till then.

yiisoft / yii2-bootstrap

Upgrade to bootstrap 4 #77