For a custom wiki django-wakawaka, i want to be able to add a WYSIWYG support.
TinyMCE is obviously the most popular plugin, used even by Wordpress.
But CK-editor seems more feature full.
Those who have used either of these or both, which is better and why. Are there some better packages, that I am missing?
Is there something that I am missing when I conclude CKeditor is better, by going through them (because it is not as widely used).
I want to use it with django and jquery, with multiple instances of WYSIWYG widget per page. Does one offer advantage over the other.
I spent some time implementing CKEditor in the last couple days. I've implemented TinyMCE in the past as well. On the positive, it's far more consistent and bug-free than TinyMCE... by which I mean, where TinyMCE "feels" buggy, CKEditor has worked around awkward browser behavior to a much greater degree, making it "feel" much more solid. On the negative, if you want to extend it, the documentation is relatively sparse. I think this is mostly because CKEditor is relatively new (its API is very different from FCKEditor), and it would be reasonable to expect the CK 3.0 documentation to reach at least the quality of the FCK 2.0 docs soon.
I've been using both editors since some years ago... Almost always I've chosen CKeditor over TinyMCE.
The reason?
Short answer:
CKEditor is very stable and very easy to use and has integrated the file manager (with an ad, but it is no problem for me), but TinyCE has not any integrated File manager.
Nevertheless, I like JCE editor (for Joomla), this editor is based on TinyMCE and works like a charm. It has a very good implementation of File management.
If you plan to use a WYSIWYG editor for a wiki, any of them are ok, because you don't need a filemanager (I think).
However, I recommend you, based in my experience, CKeditor.
The long answer is very long for this space. If you want the long answer, contact me or google around about this topic.
A cople of other Wysiwyg editors
http://imperavi.com/redactor/ (paid - actively developed)
http://xinha.webfactional.com/ (updated 2010)
http://www.kevinroth.com/rte/ (updated 2010)
http://nicedit.com/ (updated 2008 - small fix 2012)
Because of the fact that my Internship has something to do with the CKEditor. I have been developing a lot with CKEditor the last 4 months. And as my research said: If we Compare TinyMCE and the CKEditor 4.x There aren't any big difference. The only differences are: CKEditor has a smoother layout and design, CKEditor has a lot bigger community (If i remember it right a difference of 13k (35k vs 50k i remember, something like that) and CKEditor has multiple developers. The last argument is an argument that i'm not sure off. But i have been told that TinyMCE is being developed by only 1 or 2 persons and the CKEditor by multiple (and an entire community!)
If you ask me, all in favor for the CKEditor.
The negative point that is stated once above, that the documentation isn't what it is used to be since the new version. I don't really agree. The only thing is that you need to read the API. With JAVA (as example) you won't find a full explanation neither. And the nice thing is that, I and many other persons are posting questions on StackOverflow. This will support all the support you need. And for the basics almost everything is there already!
And if we have a problem, there is always one of the Core developers of the CKEditor to help us out ;)
One big bug of TinyMCE is a when you copy and paste in TinyMCE then it does not manage any space or tab and indent it to the beginning, so TinyMCE is not good but ckeditore is a more powerful editor.
Related
I am currently playing with latest Sitecore, just downloaded from SDN. The first, but quite annoying "feature" in new metro-like interface seems to be huge UX elements, big paddings in content tree between elements (it also quite ugly in Templates Builder). Also just restored a package of my existing solution (taken from 7.2) and I find it very inconvenient to use, as the one is quite big with many items.
Is there any way to switch it back to previous interface? Am also quite worrying about adapting our business users as I spent much time on justifying version upgrade and this type of people do usually judge by what they see.
I clearly understand your feelings as I had exactly the same first impression.
I dont think there is some switch to return to previous UI.
Nevertheless, it is all about themes. Default theme that is located at sitecore\shell\Themes\Standard\Default folder, so playing enough with developer tools or firebug you may produce any look-and-feel you want.
I have adjusted Sitecore 8 styles in order to fit both my visual expectations and general good look. To make it simple, I have created the module that replaces those dodgy styles with properly adjusted, to make it look similar to Sitecore 7.
Please read the blog post describing how to implement that; there also will be download link to that package:
http://blog.martinmiles.net/post/is-that-possible-to-cure-sitecore-8-styles-megalomania
The module replaces following style files from folder mentioned above:
Content Manager.css
Default.css
GlobalHeader.css
Ribbon.css
Shell.css
Startbar.css
Windows.css
Workbox.css
Hope this helps!
Update: Thank you for inspiring me with an idea of switch. I think it may make sense of implementing a SPEAK component, that allow to switch between conservative and new styles.
We are currently using Adobe ColdFusion 9 for a rather large application. We are thinking about moving to Railo or Blue Dragon.
What problems will we run into?
Will it require a large amount of refactoring or will most CFML code just work on the new system?
Do alternative engines provide support for most all official tags, or are they more limited?
In short, how divergent are these alternatives from the official language?
Is there anything we can do to make this process less painful (like upgrading to CF11 first or removing/avoiding certain features)?
My question is similar to What Notable Differences are there between Railo, Open Bluedragon, and Adobe Coldfusion?, but while that is concerned with practical differences I'm asking more specifically about practicality of transition/implementation.
It all depends on your code and the specific Adobe ColdFusion functionality that you are using. For the most part each CFML iteration supports the same tags/functionality. Where they deviate from the Adobe product is usually documented and explained. You need to dive into your code base and look specifically at the features you are using and compare those to the CFML engine of your choosing. Or you can just download and spin-up the alternate CFML engine, drop your code base in it and see what breaks.
As an example from Railo - CFML Compatibility
Railo tries to adhere the CFML standard as good as possible, Still there are some differences like missing tags and functions or a slightly different behavior. This page and the ones below should describe the incompatibilities.
And I have to question what you are basing this comment on? "and especially it's very uncertain future with them". You are running ColdFusion 9. Adobe has implemented two major version releases since then (10 and 11) and are currently working on the future release.
There are two main areas that can prove problematic when migrating from Adobe ColdFusion to Railo:
Use of feature areas that are not supported by Railo
Sloppy CFML code
The former includes integration with Microsoft technologies, such as Exchange and Sharepoint, as well as Office document manipulation; PDF forms and some of the more sophisticated document manipulations; UI "widget" integration. There are third party extensions for some of the Microsoft integrations, e.g., cfSpreadsheet, but for PDF-related stuff you'll need to roll your own using Java libraries (PDF forms and high quality HTML to PDF conversion are Adobe specialties so be prepared to do quite a bit of work in your migration if you rely on these). As for the UI "widgets", you're better off doing that the "right way" so if you rely on those, you should read ColdFusion UI The Right Way.
The latter is a harder issue to nail down. The differences are not well documented - except in experience posts to mailing lists and blogs by people who've made the transition to Railo - but they include things like:
Using scope names as variables (Railo treats scopes as reserved names for performance reasons)
Embedding comments inside tags, e.g., <cfif x gt y <!--- check boundary --->> (I've seen things like this in older CFML code and was surprised it worked).
Reliance on automatic creation of nested struct elements, e.g., a.b.c = 0 when a has not been declared.
Reliance on long-deprecated features, e.g., parameterExists().
There are many other small differences: Railo is generally stricter about syntax and semantics than Adobe ColdFusion, and often those decisions are driven by performance concerns in that compatibility with Adobe ColdFusion would make Railo slower.
Full disclosure here: I have used Railo pretty much exclusively for five years and I used to run the US arm of Railo's consulting business. That said, you need to consider that Railo is a small company (despite the backing of five fairly large former Adobe partners) with just a handful of people working on the engine, and very little awareness of the product outside the more leading edge portion of the CFML community. By comparison, Adobe have a large team and a marketing budget. Your concerns about the difficulty of finding developers will not be addressed by switching to Railo - to gain access to a larger developer pool, you'd really need to switch to a more popular language, not just a different engine.
Finally, a word about Blue Dragon's engine, specifically Open BlueDragon: the maintainers of that project have stated publicly several times that compatibility with the other engines (Adobe, Railo) is not a primary concern for them, and indeed there are a lot of modern language features that they still don't support or at least don't support in a compatible manner. Last I checked, full-script components were on that list despite having been supported in Adobe ColdFusion and Railo for many years (by which I mean using component { ... } rather than the <cfcomponent><cfscript> .. </cfscript></cfcomponent> form). The BlueDragon dialect of CFML has been steadily diverging over the years so unless you have very old school CFML, that would still run on CFMX7 / ACF8, you probably won't have much success trying to migrate to Open BlueDragon.
There are a couple good answers here and I appreciate the advice given in them. When I asked this question I was looking for something a little more specific, so now that I've had the chance to really play around with migrating our app to Railo I thought I should come back and list out the issues we've run into and, just as importantly, the severity and workarounds. Hopefully this will help others considering making the jump:
cfMessageBox:
cfMessageBox is not a supported tag in Railo. The best solution we've come up with is to create a new custom tag called MessageBox.cfm, then drop it into “{railo-install}/lib/railo-server/context/library/tag/”. This will allow it to be recognized as a core tag and referenced via “”, which saves us from updating hundreds of templates that call it. This, of course, requires us to create a message box custom tag from the ground up.
cfDiv:
cfDiv seems to be throwing a JS error when used to bind to a JS function. I'm going to guess that this is because JS binding is not officially supported (given that I can't find any reference in the official docs), and while ACF allows it as delayed execution, Railo simply doesn’t accept it. We could just create a custom tag that generates a JS setTimeout as described in (1) above, which solved our problem, but applications that actually use this tag for its intended purpose may have a more difficult road ahead.
cfWindow:
There appears to be limited support for cfWindow in Railo. Specifically, new windows need manually shown, and the destroy methods do not exist. Various other bugs appeared as well. We decided that it made more sense to just move to JQuery based modals.
cfLayout:
cfLayout support is questionable. It is based on JQuery and not Ext-JS like ACF’s version. This causes a problem because we run JQuery 1.10 right now and the built-in tag doesn’t appear to work beyond JQuery 1.8. In fact, I could not find any JQuery version within which the tag worked perfectly. We decided that it may be best to, again, just write our own custom tag based on JQuery.
cfDocument:
cfDocument works differently in Railo and seems to require more strict HTML. I found a lot of helpful information here, though as of yet I haven't actually gotten any of my cfDocument calls to work as expected.
Relative cfLocations:
cfLocations that began with a “../” and backtracked beyond the webroot would throw a weird Java error. This ended up being a bug in Tomcat, and was patched by the Railo team in version 4.3.1.003. If you download an older Railo version you may run into this issue and need to update all of your cfLocation calls.
Oracle Thin Client:
Our database guy reported to me that he setup the Oracle Thin Client, because the OCI client is not natively supported in Railo. I found this, which might be relevant, but I don't have the expertise to say for sure.
Documentation:
ACF Livedocs are sometimes aggravating as they don't touch on the more important intricacies of how some tags are implemented, but Railo's version is the definition of minimalist. I think it's fair to say that Railo has no docs specifying each tag and function and that they leave you to rely on Adobe for that, which causes a serious issue when you need to know how the two implementations differ.
In the end it seems like, as predicted by previous answers, the UI tags were the bulk of our issues. Based on previous comments I was hoping for better implementations of them that may just require a tweak here and there, but (at least for our needs) the Railo versions seem borderline non-functional and it looks like we would need to replace them completely. For us, this may not be realistic, though we are still tossing the idea around.
To be fair, here are some of the good points from our research and testing:
Performance:
Although compatibility problems have prevented me from doing much performance testing, initial spot checks show approximately a 50% decrease in execution time for most pages.
Debugging:
The debugging options in Railo are quite amazing. There are far more options for formatting, including specifying different formats for different developers (IP addresses). One incredible feature is the inclusion of a comma delimited list of query fields that were actually used in the page: this could allow you to effectively develop based on a "select *" query and simply copy and paste the fieldlist into the query at the end of development, which would save a lot of time with views as large as the ones we're using.
Cost:
This is one of the larger reasons we decided to look into alternatives. Switching just a few Enterprise licensed ACF servers over to Railo would save $20k+ over upgrading to the newest version of ACF. Further, with the performance increases you could see an even greater savings in hardware requirements. A side effect of this point is that one can keep far more up to date without the constant cost/benefit analysis of licensing costs holding up upgrades.
Support:
Without a support contract, it doesn't seem like Adobe responds to user concerns. I've had a production impacting bug reported since ACF 9 which still hasn't been fixed. Yet the Railo community is one of the most helpful and responsive I've ever seen, and developers have even responded directly to concerns and bug reports I've raised.
Longevity:
This is a highly opinionated point, of course, but while Adobe seems to be relegating ACF to the shadows more and more with each new version, Railo appears to be dedicated to growing the community. Combined with its open source nature I think this makes it a safer bet for future support in the long term, even if that support is just us taking development into our own hands when needed.
For a number of reasons, including divergent CFML compatibility, we did not even get to the testing stage with Blue Dragon.
There are two main schools of thought for doing A/B (Split) Testing:
Javascript-based solutions such as Optimizely, Google Analytics Content Experiments.
Server-side solutions such as Django-AB, Splango, and django-lean. (Also, writing your own.)
My understanding is that Javascript-based solutions are spectacular for "which color button converts better," but not so great for switching out entire page layouts, and completely unworkable for trying out large functional changes such as the sequence of pages in a funnel.
That leads me towards a server-side solution. I'm not crazy about coding my own, and will do so only if there is no other option. I'm trying to add value by improving the core functionality of my site, not by creating a better split-testing framework.
The Django apps I've found for split testing are various mixtures of unmaintained, undocumented, documented incorrectly, and incompatible with Django 1.5. This surprises me, because the Django and Python communities seem to have a strong focus on good documentation. I'm also very surprised that none of the testing frameworks I've tried has been compatible with Django 1.5 -- is testing not as core a part of the philosophy in the Django/Python world as it is in Rails?
Here's what I've found:
Splango https://github.com/shimon/Splango -- Not compatible with Django 1.5 (although most compatibility bugs I found were trivial to fix). Largely un-touched since October 2010, except for a fix August 2012 which claims to make sure templates get included in the install. Since templates don't get included in the install when Splango is installed via PyPI, either the fix didn't work or didn't get submitted to PyPI. Documentation is largely accurate, but doesn't completely cover how to set up tests and get reports. It tells you how to configure the template to gather the data, but there appears to be additional steps required in the admin interface which are completely undocumented, and I'm not sure I've done them properly.
Django-lean. Original at https://bitbucket.org/akoha/django-lean has not been updated since July 2010. There is an apparently "blessed" fork at https://github.com/anandhenry2002/django-lean which has not been changed since May 2012, when it was copied over from the original. The original's documentation is incorrect in ways that make following the examples impossible. (Though you can probably muddle your way through, as I did.) The new version's documentation has formatting problems that make it difficult to read on github. (This appears to be because it's the unchanged documentation from the old project, and BitBucket syntax doesn't work on Github.) The django-lean Google Group has not had a message since July 2012.
django-mini-lean https://github.com/DanAncona/django-mini-lean -- Updated as recently as February 2013, but undocumented.
Leaner - https://bitbucket.org/brianjinwright/leaner -- Last updated July 2012, and no docs.
Django-AB -- Last updated May 2009. Is not a package, and can't be installed via PIP or PyPI. After placing the checkout in my django app folder (and renaming the folder to ab) and following the installation instructions, I get an error loading the template loader that I have not tracked down further.
So far Splango appears to be the winner, as I've actually been able to get it more-or-less working (by manually installing the templates, and then editing them to fix Django 1.5 incompatibilities).
Can anyone point me to anything I've missed?
You have missed this app : https://github.com/mixcloud/django-experiments + https://github.com/disqus/gargoyle/
And then there's waffle: http://waffle.readthedocs.org/
It's simple, updated, maintained, but not very feature rich, it doesn't have any analytics/reporting stuff integrated. But then again, google analytics or mixpanel type of service is better for this.
I first looked at Django-AB and that is almost what I wanted, but I couldn't get it to work either. After looking at django-experiments and deciding I didn't want to mess around with redis yet, I decided to roll my own. I've tried to package it up nicely and make it easy to use for the beginner. It's super basic.
https://github.com/crobertsbmw/RobertsAB
You can swap out entirely different page layouts with Google Analytics Experiments (their default experiment setup will redirect users to a different URL for each variation you have), although in general its much easier to interpret why something is more successful if you test smaller things against each other.
You are right that testing different funnels and user flows against each other using Google Analytics would require a lot of manual setup; although theoretically you could do it by swapping out different links and tracking your users with UTM campaigns.
For smaller A/B tests within the same page, I ended up using Google Analytics Experiments and writing a custom Django CMS plugin for adding a few variant options to a template, which queries the Google Analytics API and displays the correct variant using Javascript.
I have installed FaLang component to use multi-language support everything is working fine except the alias structure. When we are switching the language the URL not get changes as per the added alias conversion added into admin section. I tried almost all activities enabling both plugins but still the problem is as it is.
I believe Shaz is correct, there is no solution within FaLang at this time.
I asked the developer about this in Feb 2012 and he mentioned he was still working on it, but currently, with FaLang v 1.1.7 it still doesn't happen.
Initially I was really excited when FaLang appeared, but now I'm not so sure. I work on a lot of multilingual sites, and I don't want to get get stranded with multilingual Joomla 2.5 sites as has happened to me with many Joomla 1.5 sites I developed with JoomFish.
I know many well respected developers like FaLang, but FWIW I now favour the native language capabability built into Joomla 2.5. It's not perfect, but for now they have my confidence that it will improve.
Unfortunately this doesn't solve your problem, but if you need an introduction to how it works, here is one good link:
[http://bit.ly/LpPoV2][1]
and another one
http://www.youtube.com/watch?v=gnhVVtyejPg
Initially I found the process a bit cumbersome, but once I got used to it, it's works quite well ... and yes, the aliases work as you would expect.
Good luck!
I am at present building a medium-sized educational website containing text, academic articles, blog, audio book excerpts, mathematical demos, etc., using custom CSS styles. I am leaning toward two ready-made solutions:
django-cms; and
textpattern.
I have ruled out WordPress because customization is not so easy. Joomla is overkill for this website and the table based design it uses is against my philosophy.
Because I have a number of years of experience in django, django-cms seems to be the natural way to go, but textpattern has more out-of-the-box features and is well supported.
What are the pros and cons between django-cms and textpattern based on prior experience of the people on this list?
Many thanks.
For a comparison of CMSes the best site I have found so far is:
http://cmsmatrix.org/matrix
Over 1200 CMSes are listed and you can compare CMSes by clicking on the checkboxes provided this helped me make my decision and ended up turning back to one of the popular CMSes namely WordPress.
Because I have a number of years of experience in django, django-cms seems to be the natural way to go, but textpattern has more out-of-the-box features and is well supported.
django-cms also has a lot of features from plugins and are well supported too.
django-cms is a fine software which even has it's own hosting site. If as you seem to suggest, the only reason you are looking at textpattern is because it has many out-of-the-box features, then you should really go the natural way with django-cms.
I'm a fan of Textpattern and have been using it for years now. It's benefits are its simplicity and light-weight making it perform well. However, these might be an issue for you if you are wanting to build different content types. Textpattern's interface treats all article content as the same (unless you start install a load of plugins to tweak this). This is fine if your site is primarily for articles, but from what you've said in your question I suspect not.
It is really simple to download and install; so I'd recommend giving it a quick look to see what it can do for you.