i face some conflict using bootstrap 3 and liferay framework for example the navbar class stop in the framework when we put the main bootstrap style .
I need to limit scope of bootstrap using unique class on body
any help
Liferay 6.2, out of the box, uses bootstrap 2.3 (see the reason behind this) and conflicts with bootstrap 3 are (kind of) expected.
In order to get started creating a bs-2.3 theme, you might want to check Juan Gonzalez's blog (released today, just in time). In case you insist on integrating bootstrap 3 with Liferay 6.2, you'll have to do a lot more work than with 2.3. To "face some conflict" is not quite a sufficient explanation for whatever you're experiencing. And if bs3-integration would be as easy as mitigating some conflict you face, trust me, it would have long been done.
Related
I have a more generic question. We want to install an editor in our application to allow teachers to teach others through learning posts. In order to accomplish this we plan to start with the classic ckeditor5 and then customize it to allow certain users to add things like science and math formulas, slide show presentations, etc.
Are we too early for this with CKE5? Should we stick with CKE4 and use the variety of plug-ins that are offered out of the box.
I just want to make sure CKE5 is ready for prime time.
Thanks so much for your response.
Ckeditor4 pros:
A lot of plugins available and easy to create custom plugin
UI customisation easy
A lot of pre-build skins available including Microsoft word 2013
Custom build can be easily made with online builder
CKeditor4 cons:
Difficult to implement with frameworks like react. Has to be implemented by creation script elements and appending to the DOM.
CKeditor5 pros:
Direct implementation with react possible with rpm packages.
Basic UI and toolbar looks a little better than ck4
CKeditor cons:
Very Less plugins available.
Plugins need to be installed as packages
UI customisation difficult
From Which editor is best:
The choice between the editors depends on the user’s specific needs
and requirements.
You should consider continuing using CKEditor 4 if the compatibility
with old browsers is a must for you or if features that are essential
for you are not yet available in CKEditor 5. However, being a totally
new editor, with time CKEditor 5 will have more and more features
developed and available for end users to benefit from. At the same
time, we are determined to continue the CKEditor 4 development and
maintenance for some good time still. The CKEditor 4.x line is under a
“Long Term Support” (LTS) programme which means that its development
and support is guaranteed until 2023, giving the users enough time to
make a move towards CKEditor 5.
If great user experience and clean UI are your priority and the
features currently available with CKEditor 5 Builds (Classic editor,
Inline editor, Balloon editor, Document editor) are sufficient for
your use case, then you should consider using CKEditor 5 Builds.
To find out more about CKEditor 5 Builds refer to the CKEditor 5 Builds documentation.
If you wish to create your own text editing solution and have full
control over every aspect of the editor, from UI to features, and the
possibility to enable real-time collaborative editing inside the
editor you should consider CKEditor 5 Framework.
To find out more about CKEditor 5 Framework refer to the CKEditor 5 Framework documentation.
From How to migrate from CKEditor 4 to CKEditor 5:
When compared to its predecessor, CKEditor 5 should be considered a
totally new editor. Every single aspect of it was redesigned — from
installation, to integration, to features, to its data model, and
finally to its API. Therefore, moving applications using a previous
CKEditor version to version 5 cannot be simply called an "upgrade". It
is something bigger, so the "migration" term fits better.
CKEditor 5's architecture and custom data model makes it possible to enable real-time collaborative editing.
In 2019 Chris Harris wrote this comment:
We have been using CKEditor 4 for some years, and since support is to
be dropped soon, I have just spent several days working on migrating
to CKEditor 5. This has been a frustrating experience, and as a
result, we will probably be moving to some other alternative instead.
My frustrations with CKEditor 5 include:
There are few features by default, and every new feature needs a different plugin, each one needing research and time to add in.
Adding plugins is not a simple download/install. Each one needs editing the main build config file, doing a rebuild, working out the
config we want, putting it in the build config file, building again.
None of which is difficult, but certainly more hassle than I would
expect.
CKeditor 4 had a re-sizeable window, CKEditor 5 doesn't. Adding CSS3 resizeable works, but had some odd effects when changing focus
from the editor to the page outside it (the window would resize to its
default size). I'm not saying that's the fault of CKEditor 5, but it's
another example where bringing it up to 4 level is not simple.
CKeditor 4 used inline element styling for e.g. floating an image left/right. CKEditor 5 doesn't, it adds a class to the element. So the
code produced by the editor doesn't work right without additional
styling, which adds complication to the deployment of the code it
produces.
My research suggests I'm not the only one who would like a simple
download that provided the same functionality as CKEditor 4, but it's
not available - by design. And I've come to the conclusion that the
design of CKeditor 5 has been driven ideologically, providing
something that the creators think developers ought to want - rather
than something they really do want.
See more on:
What is different about CKEditor 5 compared to CKEditor 4?
CKEditor FAQ
Migration from CKEditor
Bringing collaborative editing to any application
We have website which built in yii 1.1 version, now we would like to convert it to version 2. But we already have a lots of functionality and we do not have much time to do everything by scratch in yii 2. please do suggest.
I don't think there is a fast way of converting or migrating from Yii 1.1 to Yii2. They are similar in some ways but different enough.
I would recommend you first read most of The Definitive Guide to Yii 2.0, which includes Upgrading from Version 1.1.
In my opinion the best you can do is try to replicate the same modules and their functionality one at a time, trying to reuse as much code as you can from the 1.1 version. A few things that i think would be important are:
Create the new Yii2 models using Gii and adapt methods from your Yii 1.1 models. Edit and add validation rules as needed. There are many rules that might not have been available in Yii 1.1, however it can also be true the other way around.
Generate Yii2 modules with Gii. Just need these to create a better project structure. If you didn't use modules on Yii 1.1 i would recommend doing so for Yii2.
Generate Yii2 CRUDs with Gii inside the corresponding modules. This will help generate the controller, actions, views and search model needed for basic CRUD functionality. After that, you will need to edit the views and controller to fit your needs, which you can use your 1.1 code for reference.
Install needed extensions and widgets using composer. Many extensions from Yii 1.1 have updated versions for Yii2, but for those that do not you will have to find substitutes, which shouldn't be too difficult, although you will most likely have to read the documentation for both familiar and new extensions.
In the end you will need to spend time to have a Yii2 version of your website, there is no easy and fast way to jump
You don't need to convert your application completely you can use both at same time please have a look to
http://www.yiiframework.com/doc-2.0/guide-tutorial-yii-integration.html
Whats is the use of Bootstrap sub theme in Drupal 7 and why it is recommended? There is lot of articles out there on "How to Bootstrap sub-theming" but none of them are available for why?
As it is said on Drupal.org:
Sub-themes are just like any other theme, with one difference: They
inherit the parent theme's resources.
A Bootstrap sub-theme allows you to inherit from the Bootstrap framework itself. It brings you several benefits:
No need to download any contrib modules, the Bootstrap sub-theme kit should be enough.
A strong CSS base, with accurate variables customization.
Respect of web standards.
Great modularity.
...
I hope I answered the question.
I recently inherited a Rails 2.3 application that I'm now trying to upgrade to Rails 3. Cache-money is an integral part of the application so I want to make sure we have the same functionality in place when we go to Rails 3. However, my research on the subject has shown that cache-money is not compatible with Rails 3 (due to the use of unsupported AR methods :find_every and :find_from_ids).
I've seen a couple of comments and blogs mention that implementing the type of write through caching with Rails 3 that cache-money provided should be a trivial task. Any ideas on how to approach implementing write through caching with Rails 3?
Last week I launched a new write-through-cache gem for Rails 3, see
https://github.com/orslumen/record-cache.
The reason I built it, is because we were using cache money in a Rails 2.3 project and recently migrated to Rails 3. So chances are, it will also serve you well.
Writing your own write-though caching in Rails 3 does not sound like a trivial task to me. If you do find a trivial way, please be sure to copy me in on that.
We are in mid of a project where we have used an extended Dojo 1.1.1 to meet the customer requirement and add richness.
But there are quite some bugs and performance problems with this version of Dojo and
we are looking ahead to migrate the Dojo version to overcome both the issues, but the migration cycle seems to be quite painful and may not be yield expected result.
The concern we have is with the various extension which we have created with the version of Dojo for components that were provided in 1.1.1 and the impact on them after migration.But, the advantage we see are equally important.
As per Dojo , they have kept some level of compatibility with version 1.1.1 but i have not seen any discussion around this anywhere.
Has any body else previously done
migrated between Dojo version?
Will the components like Grid will
work as expected or will i need to
carry out a refactoring exercise?
Do we have any commercial support
available as the forum seems to
deprecated?
Any help or suggestions are welcome
Dojo has had a policy of freezing and supporting public APIs since 1.0. Migrations prior to 1.0 were extremely painful. Now, it should be much better, provided you use only public APIs. Code written for stable JS APIs in Dojo or Dijit in 1.1 should largely still work. Exceptions are noted in the release notes, which you should explore (good luck finding them... unfortunately the site is a bit of a mess)
If you wrote any custom widgets, you're probably in for some extra work. dojox.grid was not particularly stable at that point, and it has also seen a major rewrite since then (there is an old 'compat' layer you may wish to use)
Regarding for forum, like the note says, you can either use the active dojo-interest mailing list or post questions here at SO. There are some firms which offer commercial support, but that's outside of the scope of Dojo as an open source project. (try googling 'Dojo commercial support' or asking on dojo-interest)
I have done 5 dojo migrations now (from 0.2 -> 1.4) over the last few years. Although the API does not change, you will often have coded in workarounds that no longer work after upgrading. Things I have noticed:
quality in 1.4 is VERY good and worth
upgrading to (even from 1.3)
although
the API does not change, little
things that are not public often
change slightly (diji.Tree
itemNodeMap -> itemNodesMap in 1.4)
build options are usually added each
release but not always publicised -
strage really as they are always
useful improvement
since you are 1.1.1, you should change all your set attribute calls to 'attr' - this could take a while to do.
As for commercial support, you could try Sitepen