I recently upgraded from Wicket 7.x to 8.1.0 and wondered what happens to some of the ClientProperties methods, that are now marked #Deprecated without a hint why or what will become of them.
The migration guide doesn't mention them either.
I found this commit introducing the changes, but couldn't trace it back to a Jira story (WICKET-6544 is about buggy user agent detection, i don't see the link here).
So what will become of this feature, will it be removed without replacement?
Thanks for your question: User agent detection was indeed deprecated in Wicket 8 and will be removed in Wicket 9.
I've updated the migration guides, users are encouraged to switch to specialized libraries like https://github.com/nielsbasjes/yauaa now.
Related
A day ago my prestashop website, in the comment box of the blog started to display the following message:
And entering the post that explains how to migrate the version of TinyMCE , I do not understand very well how to perform these steps in my prestashop.
How can I update this?a
if you are using a third-party module to make your blog it might be is including its own version of TinyMCE. You should try to dig in its code to understand that.
If this is not the case, the blog uses TinyMCE which is normally included in Prestashop core.
On said that, this second case is likely to be the one. Update the e-commerce unlikely will solve your problem. I honestly don't remember in which version they are with TinyMCE but doing an upgrade like that might break back-office editor forms so I don't think they are keen on that at the moment. They are doing a major rollover to Symfony, I am pretty sure this is their priority right now. As said in one comment, Prestashop's dev team has to solve the issue on their side.
I'm looking for some kind of guidelines, known issues, risks or any kind of information to help migrating an app written using idangerous Swiper 2.5.5 to the latest (4.0.7 as of December 2017). My major concern is support for latest Chrome / FF for desktop, although mobile and other browsers are a plus.
I found this Change Log page with some release notes from version 3.0.0 on. I found nothing about older versions and no guide to upgrade, specially useful for major versions
Obs: the same question was originally posted on their forum
Here are a few lessons learned after some initial tests (the list is most likely not complete). APIs updated:
jQuery/Zepto usage changed from $('.swiper-container').swiper({}) to new Swiper ('.swiper-container', {})
resizeFix() removed
reInit() removed
navigation APIs renamed:
swipeTo() to slideTo()
swipePrev() to slidePrev()
swipeNext() to slideNext()
pagination param type changed from '.tgt' to { el: '.tgt'} obj
I have TYPO3 6.1.x system running. I have several own extensions using extbase. Now, Extbase logs insanely much deprecated function calls. How can I stop this? My deprecation log file reaches 1 GB in size in about 1 or 2 days.
In theory, the deprecation logs are considered very helpful to developers-it should be enabled while developing extensions and migrating TYPO3 core versions.
To actually disable the deprecation log, you have 2 options:
You can either set the relevant flag via the install-tool: enableDeprecationLog
You can add the following to your AdditionalConfiguration.php
$TYPO3_CONF_VARS['SYS']['enableDeprecationLog'] = '';
For a quick reference, have a look at the TYPO3 wiki page.
Despite being enabled or not; you can always safely remove the deprecation log files.
You can't disable per ext as Cedric wrote, anyway I'd like to mention other thing: most of deprecated methods of TYPO3 API has newer version so you should consider fixing your code (de facto in most cases that's quite fast process). If you are using some modern IDE it will hint you that method is deprecated and will suggest you new one via the typo3/sysext/core/Migrations/Code/LegacyClassesForIde.php class - preview it.
For an instance
t3lib_div::_GET('foo');
becomes:
\TYPO3\CMS\Core\Utility\GeneralUtility::_GET('foo');
(or GeneralUtility::_GET('foo'); when u use imports)
Get in mind that these classes are removed in version 7.0 of TYPO3
Ubuntu is usually a cutting edge distro. But why does it stick to a 2011 version of Eclipse when we are 4 years into 4.x development?
It's not even optional and cannot be installed from the repositories. And it's not 'easy' from a download either. For some reason, the Java SE 7 reference implementation, OpenJDK, is not enough, and you need the Oracle version. Why? This isn't available from the repo's either, and you need some weird untrusted 3rd party repo for that or follow a whole chapter on how to install it yourself.
There were problems three years ago. When Juno 4.2 came out, it had a lot of performance issues. Eclipse Director Mike Milinkovich explains one of the reasons is lack of funding. For the first time in a major release:
"The performance test were turned off because the Eclipse platform team has a serious resource issue."
For that reason, developers released unnamed and unpromoted version 3.8 simultaneously with 4.2 to bridge the gap for this (hopefully) temporary problem, and it's popularity caused a notable trend downwards amongst developers. As one Eclipse b3 developer mentioned:
"I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"
The 3.8 release is still a popular alternative to the 4.x branch among developers (ask my colleagues or google), I think mainly because of (genuine) trust issues. But the bridge (read: support for 3.8) has closed now that 4.3 is released.
The core problems (funding and developers) have not been fixed though, as seen by Google's gesture of donating money to the Eclipse Foundation in the hopes that other companies will follow suit. Does this mean that 4.3 is still not up to par with the 3.x standards?
This is not a problem with a plugin or a feature for a specific language, this is a problem within the core of the platform itself. (But I'm using WST with Javascript and V8 plugins for PHP and Node development in particular.)
This is not a specific platform problem either. There are similar complaints from Linux, Windows, and OSX users. (But I'm using Linux (Mint 13).)
On the one hand you have people telling the EOL for 3.8 "proves" that 4.3 is fine now. On the other hand (see comments):
"I've moved back to 3.8 due to constant crashes on ubuntu with 4.3"
3.8 is far from problem-free and I wouldn't mind to get a smoother development experience. So I am wondering, why is Eclipse 4 'kept from us' by the people who decide what software versions are 'good for us' (AKA what goes into the official repository)?
lucid (10.04 LTS)
Eclipse 3.5.2-2
precise (12.04 LTS)
Eclipse 3.7.2-1
raring (13.04)
Eclipse 3.8.1-1
saucy (13.10)
Eclipse 3.8.1-4
trusty (14.04 LTS)
Eclipse 3.8.1-5.1
utopic (14.10)
Eclipse 3.8.1-5.1
Update 2014-05-30: I just tried Kepler (again) and it still suffers from UI glitches out of the box. E.g.:
And no, changing the inactive window toolbar background color in preferences does not fix this. (Even if it would, this would be a silly default choice).
I would like to know, from someone who is not positively or negatively biased because of their own highly specialized and tweaked workflow - preferably from someone with experience in the Ubuntu package maintaining process for non-trivial packages - why this decision is made by a team of professionals who know what they are doing for the most widely used Linux distribution out there?
Eclipse Juno was released 2012-06-27. On 2012-07-17 a bug concerning the responsiveness of the UI was reported. Four months later, around 2012-11-14 the first patch was released to the official update-site.
Many users, however, completely missed the release of the patches. I assume the information drowned in the FUD, and other more important news, that was spread around that time. At the end of 2012 I posted an answer on SO. Apparently I was not the only one for whom the patch fixed this performance issue.
On 2013-02-22 Eclipse 4.2.2 was released, which contained the same patch, yet I kept receiving upvotes for my answer on SO until June.
Probably the only known fact among developers is that Eclipse had serious performance issues at some point. However, the knowledge about scope, magnitude and duration of these issues seems to me like a series of common misconceptions.
There was a four months period during which it was a good idea for many Eclipse users to stick with the 3.8 branch. I say "many" because I worked with 4.2.0 and 4.2.1 and it was O.K. for me. Subjectively, switching tabs was about two times slower and the IDE froze maybe once a day for a couple of seconds. For colleagues of mine the problem was much more severe. I assume it depended on your setup and on your workflow, however, I never felt like investigating further because I knew the platform developers were working on the issues, and there was a good fallback, using 3.8.
One year and three Eclpse releases later these serious performance issues are still fixed.
Of course, this doesn't mean that there are no more performance issues. As of now I find 1979 reports in the Eclipse bugzilla with the keyword "performance". This doesn't mean that Eclipse is very buggy, but only that it is very well documented and open. Whether or not you are affected by any of these issues, again, depends on the setup, the plug-ins you are using and your workflow. I am a Java, plug-in and EMF developer. I work with medium to big work spaces (~1M LoC), and Eclipse 4.3.1 is fast enough. The 3.8 release is not an option for me because as Eric said, it won't receive all of the important updates. People will still continue using it in the future. Many of them will also continue using Internet Explorer 5.5.
If you try the 4.x branch and notice any performance issues, please report them, but be specific about your setup.
From the official Wiki page:
Several major performance defects have been addressed in Juno SR2
(4.2.2). Community members have confirmed that these fixes
substantially address the performance problems with editor and view
opening, closing, and switching. These fixes are widely available in
Juno Service Release 2 (February 2013). All defects are also resolved
in the Kepler (June 2013) release stream.
new Features
Your statement "3.8 release was specifically released as a faster and more stable alternative to 4.2" is clearly incorrect; 3.x has gone into its 'end of life' maintenance and was most certainly not released as an alternative to 4.x.
While folks are welcome to continue to use the 3.x stream if it suits their needs please recognize that as the various projects move forward there will be significant divergence in the features available between the two versions...
Is three20 still actively being developed? From the three20.info site, I see no new features/UI elements since earlier this year when I looked into it.
Besides three20, is there another good framework out there?
As far as i know, Three20 is only maintained by community (bug fixes). Jeff left the project and decided to clean up that mess & provide solid documentation.
He recently started a new project on github called Nimbus, his plan is to port all features of Three20 to Nimbus without the problems we face today with Three20.
I haven't given up on three20 yet. It's a good framework and it saves me hours of work. I'm submitting bug fixes and small improvements to the framework from time to time and I see some activity in github. (not as much as it used to be)
I tried using nimbus, and I was really impressed with the documentation and existing classes. However, note that the developer went to work in CA and said he'll contribute less to his new framework.
The three20.info site is not maintained, but you can download the latest version from github.com/facebook/three20.