After Upgrading successfully by transferring upgrade zip file and completing upgrade wizard process after host login, Error HTTP 503 came up when I clicked on "Visit Website" button. After going through Log files below error log was found
DotNetNuke.Services.Exceptions.Exceptions - System.IndexOutOfRangeException: TermsTabId
at System.Data.ProviderBase.FieldNameLookup.GetOrdinal(String fieldName)
at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name)
at System.Data.SqlClient.SqlDataReader.get_Item(String name)
at DotNetNuke.Entities.Portals.PortalInfo.Fill(IDataReader dr)
at DotNetNuke.Common.Utilities.CBO.FillObjectFromReader(Object objObject, IDataReader dr)
Issue happened at Live site
Going from DNN 9.1.1 to 9.3.2 (and maybe beyond that) requires some careful attention to detail. In that series of releases, there are some important breaking changes, most of them related to the removal of APIs that have been deprecated since DNN 7. Most of these issues can be solved by making sure that any modules you have added to the basic DNN Platform have been update prior to doing the upgrades. Essentially, you'll want to make sure that your modules (and possibly skins) are compatible with the DNN version to which you are upgrading.
Read the release notes for all of the intermediate releases, especially 9.3.1 and 9.3.2. There are some important breaking changes to DNN.
Also read the notes at the bottom of https://dnndocs.com/content/getting-started/setup/upgrades/suggested-upgrade-path/index.html
Before doing the upgrade, you should identify any modules that need to be upgraded because of breaking changes and removal of deprecated APIs.
If you need additional help with this, I'd recommended visiting the forums at dnncommunity.org and asking questions there. Among other things, you may find that the community of people who can help is larger over there.
Related
I have just started a new site where I am using 2sxc version 11.11.4 (started with 11.7.3 and upgraded to see if that would fix it). I have the data and views set up just like I have done on another site using version 10.25.2. On the newer version though, I'm unable to use the remove button/action. I did some searching and found a few references to adding lines to the web config file (https://github.com/2sic/2sxc/issues/1654, https://github.com/2sic/2sxc/issues/2205). I tried this and it worked great.
So, my question: will a fix be implemented for this or will we have to add these lines of code to the web config file on any site we use 2sxc on?
Also, could these lines of code affect any other DNN features, other modules, etc.?
I think you are talking about my solution here
https://github.com/2sic/2sxc/issues/2205#issuecomment-705647892
This is specific to a server where the WebDAV features have been added/enabled in Windows. I do not think its an issue that can or will be fixed in 2sxc.
I do know that it is safe to add those two items in web.config. All its doing is telling ASP.NET to NOT make WebDAV available in this application's (DNN's) context. I am not aware of any DNN feature or modules that need or use WebDAV. Its just something handed down from the server because its installed and its causing a weird change in behavior that makes the DELETE (and other) command types get ignored (IMHO, presumably because they are handled before they get to DNN).
I've been working on a small Google App Engine (standard environment) project that uses Cloud Endpoints v2. My code is largely based on the quickstart provided by Google.
Everything was working fine, but I re-deployed today after having not looked at it for a few weeks, and I'm getting the following error when I attempt to call the endpoint:
error: An error occured while connecting to the server: DNS lookup failed for URL: metadata.google.internal
This wasn't happening before. It seems to be happening when the endpoints package is being imported by Python.
My endpoint doesn't do anything fancy - I haven't changed the source from the sample EchoApi. The error ends up in the GCP Logging console no matter if I try to access the API through the API Explorer or via Curl.
I don't get any errors during deployment.
Edit #1
Some further information:
The error originates from within Google's code that is included with the google-endpoints package which I've included in my lib folder, per
the documentation. Specifically, the error occurs on line 54 of google/api/control/wsgi.py.
Basically, it's making a request to metadata.google.internal using urllib2.
I'm guessing this address is only available from within the Google Cloud, and that for whatever reason, the instance that's hosting my app can't do a DNS lookup on it.
Edit: #2
Dug a bit further.
It seems that the error originates in the google-endpoints-api-management package. Changes committed to that package on October 19th seem to have introduced additional platform reporting. metadata.google.internal is queried to check if the code is running within the Google Container Engine, then it blows up, because the metadata address doesn't resolve.
Here's the commit:
https://github.com/cloudendpoints/endpoints-management-python/commit/0a37d0e443091053ed03e455e06d3a0ae770999f
The google-endpoints package only requires google-endpoints-api-management >=1.0.0b1. On my end, things were working fine on version 1.0.0b2, but then I built a new lib folder, which brought down 1.0.0b5, and things went sideways. Required packages haven't changed between b2 and b5, so I'm thinking I may be able to just downgrade back to b2 for the time being. Haven't tried it yet.
Sent the Google Dev an email. Perhaps he'll chime in with further tips.
Edit: 2016-11-07
Tested downgrading the google-endpoints-api-management package to 1.0.0b2. Seems to be working, kludgy a fix as it is. If you're using the lib folder, the following will scrub the newer error-prone wsgi.py file and put back the older one:
pip install -t lib google-endpoints-api-management==1.0.0b2 --upgrade
Not pretty, but it may just get you back in business.
On a side note, the Google engineer promptly replied saying that he would take a look at this issue soon. With luck, endpoints v2 will eventually come out of beta, 'cause I'm really liking it so far.
This will be fixed in an upcoming patch to the google-endpoints-api-management package (which will be 1.0.0b6). It will probably be released sometime on Monday, 11/6.
If you'd like to continue testing right away and this error is blocking you, you can go back to 1.0.0b4 until 1.0.0b6 comes out. Everything should still work as normal with that version.
Thanks for bringing this to our attention! We're doing our best to iron out all of these wrinkles now during beta in preparation for our first general release.
EDIT: 1.0.0b6 has been released and resolves this issue. Thanks for your patience during our beta phase!
(Posted solution on behalf of the OP).
Google has released version 1.0.0b6 of the google-endpoints-api-management package to address this issue. It solved the problem for me. For anyone who is encountering this problem, clean out your lib folder and re-install the google-endpoints package. This will bring down the new google-endpoints-api-management package with it.
Thanks to Brad at Google for really quick action on this.
I've been trying to upgrade DNN version 4.09.05 to 5.0.0. and higher but I always encounter errors in upgrading. Each version presents different errors. I really need help.
Due to the vagueness of your posting, we aren't going to be able to help you much except point you to the Wiki for upgrade scenarios
http://www.dotnetnuke.com/Resources/Wiki/Page/Upgrading-DotNetNuke.aspx
First things first, you should just attempt to upgrade from 4.9.5 to the latest 6.1.1 release, see if that works (after backing everything up)
I tested that it is possible for Android to pass newVersion < oldVersion to SQLiteOpenHelper.onUpgrade() method, ie. it wants the application to downgrade its database.
I don't want to handle this case, though I would like to notify the user somehow that there exists a newer version of my application (which she apparently had installed previously) and that's the one she should be using.
Any ideas what would be the best way to achieve this? Toast? AlertDialog (but in what context)?
Indeed, you can call that method with a "new" version smaller than the "old" version, but when would it ever happen?
Unless you expect your users to manually reinstall your app, overwriting it with an earlier APK, there's no need to think about this.
We have multiple active branches of our app (e.g. v1.x and v2.x), and we deliver releases internally for testing. This means a tester occasionally installs the older version over the top of the newer one.
It is a good idea to cope gracefully in this scenario (a helpful error popup, blow the database away, etc), otherwise the tester see a "Force quit" message, and then we have to look at the adb logcat logs to confirm that this was due to a version mismatch.
Initially I worried that there were other reasonable scenarios where this could happen, e.g. when Reactivating an older version in the Android Market (e.g. due to a catastrophic bug in a new version).
However, the Android docs seem to say that you can't Activate an older release:
You cannot activate a new APK that has a version code lower than that of the APK it's replacing.
So to hit this scenario you would need to rebuild the older version with a new version number before you can Activate it. IMO it is still worth coping with this scenario, as somebody could easily make this mistake at 4am while trying to backout a bad release!
Is there a simple and automatic way of checking if a visitor to my website (written in asp.net) is using the latest version of his browser? This would allow me to display a message to inform them that they're running an old version and that they might want to upgrade.
My website is tested on most broswers but I don't test old versions (such as Internet Explorer 6 etc). When one of my visitors is using such an old version, basically, I would like to encourage (not force) them to upgrade.
Of course I could do this myself by getting the version of the browser and look it up in my database but I don't want to have to maintain a 'browser version' database myself.
Any ideas?
Speaking as a user of websites, if I come across a site that advised me to upgrade my browser then that would be an immediate black mark against that site.
I might not be able to upgrade (if I'm accessing from a corporate network for example); I might have a specific reason for using a particular version (if I'm a web developer wanting to ensure compatibility with my user community for example).
So personally, I would say that a blanket disclaimer that you don't test this site on earlier versions would be the way to go. That's quite apart from the technical challenge of what you want to do.
Edit: as Yeti points out, however valid my concerns, I don't answer the question directly. This is done in Pace's answer, and the w3schools resource he points to gives you what you need to do this on the client side.