I have a bunch of code I'd like to upgrade from using
JSON.net 4.0.3 to 4.5.8 or whatever is latest. Are there any known
breaking changes, or a place I can look to find them?
I saw this: http://json.codeplex.com/workitem/22498 which looks to
be fixed in 4.5.3. I saw this as well:
http://james.newtonking.com/archive/2012/03/20/json-net-4-5-release-1-iso-dates-async-metro-build.aspx, which I might need to address.
Releases from 6.0.4 forward have release notes on the GitHub repository for the project.
All the releases have their changes listed on the blog you link to ( http://james.newtonking.com/ ) and on the particular article he says that the package will now only make breaking change on major version number changes (semantic versioning, hurrah!).
So by trawling the blog for each post relating to a major version change (i.e. 6.0.0) you can work out what changes you need to worry about. I have not seen a better compiled list.
Related
I have come across something, I have seen referred to as 'Version Control'. I assume this is the process of assigning a version number to WordPress, Themes, Plugins etc.
Is there some kind of 'standardised' model to version control? For example, would a major change be considered when certain folders/files are modified? Maybe its the amount of changes? Similarly, what would be considered a minor change?
If there is no 'standardised model', then would it be fair to say that Version Control is pretty Subjective?
It really depends on the author of the plugin or the theme. But here is how semantic versioning works:
Lets say a plugin is versioned 1.2.0
MAJOR version when you make incompatible API changes, (1)
MINOR version when you add functionality in a backwards-compatible manner (2)
PATCH version when you make backwards-compatible bug fixes. (0)
Again, it really depends on the author, for example this particular author versions his/her plugin 1.10.7.1 or in case of Jetpack, all versions are normally like 5.4 and sometimes versions with patches .
If you are concerned about a particular version, you should always read the changelog.
I inherited a Plone installation (version 2.5). It was critical that I upgrade it to 3.3.5.
I set up a test environment and got the old version working. I set up 3.3.5 and went through the migration steps. Now whenever I go to a page I get:
Macro Expansion failed
exceptions.KeyError: 'header'
I've looked in the front_page template (I think that's what it's called) and it has that error listed front and center. I tried removing the macro tag and it gives me an error about the macro needing to be within the tabs.
From looking at more documentation it looks like Plone has moved away from using macros. Is there a quick fix to get our site to work as is, or will we have to do some re-writing?
EDITED: From the comments there is a mention of Add-ons needing to be upgraded. How do I know if I have add-ons? How do I know if they need to be upgraded? How do I find out how to upgrade them? The documentation is full of "whats" but very sparse on "Hows".
EDITED: I found the header issue by looking through the old one (there was a header template that was in the old installation but not in the new one, had to figure out how to get it in there), now it's giving me an error about a user-macro="scripts/macros/jsrenderer" and if I remove that there is one for css. These look like standard entries for plone (since the exact same syntax comes up when I google these...but I can't find the location of the macro anywhere. Is this something that has changed in version 3?
EDITED: I think I've got it under control now, jumping back and forth between the two installations. Such a Pain.
Let me know if you need any code. Thanks for your help.
I can only give hints for debugging this error. What you can try is:
Can you find a define-macro="header" in the code? If not, that's what your template tries to look up and fails.
In the ZMI, check the portal_skins -> properties tab. I think most of the views (templates) are mapped as filesystem directory folders. These need to be registered in each skin layer. The order of each entry is important, as that's the way macros are looked up. Check if each layer has access to each directory view.*
Check if a custom product defines yet another 'main_template.pt' which (re-)defines different macros.
From my experience, a lot of customization happened in page templates. In the traceback you should find, which template the error is happening. Try to look up use-macro="" statements which perhaps point to macros which are different or don't exist anymore.
Furthermore, no - page templates with macros are still in use. Good luck!
After migrating from 3.3.5 to 4.1, some folders show their contents properly while some give this error
AttributeError: getLocallyAllowedTypes
How can I fix it?
faber
You really need to include more detail when asking others for help. When asking for help with software, it's very important to include not only tracebacks but also what add-ons you are using. Your original question should have mentioned that you're using contentleadimage. It also should have mentioned that you're using Collage, something I only found out from the traceback.
At any rate the problem appears to be that Collage, contentleadimage, or some combination of your add-one are not compatible with 4.1.
I ran into this problem myself when using wsapi4plone.core to sling content across. Some of my ZODBs have been upgraded all the way from 2.0.5 and we decided this migration would be a good opportunity to 'clean' the content.
The fix is to go to the offending folders on the content source, and from the 'Add new' > 'Restrictions' and check the appropriate choice.
MY suspicion is that these were older folders (prior to the property existing) that had not updated properly and had never been edited since. I didn't dig too deep since there were only a few.
Wordpress 3.1 came out recently with a lot of new features, and as I can see, there's a big change in support for translation. The context feature of GNU Gettext (msgctxt) is now used a lot in Wordpress's code, some e() and _() are replaced by _x() and _ex(). And... it's causing a problem for me.
I'm using PoEdit to edit the translation for Wordpress, but currently it doesn't support msgctxt. I know how to manually edit the .po file to translate a string that uses msgctxt, but it's a hard work. And, the bigger problem is that when I use PoEdit's Update button, all my hard works... go away, the things that I changed by manually editing the .po file go away!
So now, I come here to ask you, do you know any translation toolkit (like PoEdit) that supports GNU gettext's msgctxt? Please tell me, thanks a lot for your help :D
Great news: PoEdit 1.5.5 now supports msgctxt! The key thing to get right is the keyword sources configuration within your Catalog properties. For _x and _ex it should look like: "_x:1,2c" and "_ex:1,2c". Covered in more detail here: http://wp.tutsplus.com/tutorials/theme-development/translating-your-theme/
you can use PoEditor.com it supports the msgctxt!
Regards
I realize this is a year-old question, but have you tried Automattic's own GlotPress?
It's still a work in progress, and you have to install it from the Subversion repository, but it does support translation contexts and it allows collaboration.
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.