I'm recently going through my first Kentico upgrade on a site that was previously handed to me from somebody else. There were some hinks initially, but I have to say the V8.2 to V9.0 upgrade is gone off with a degree of success. There is one last issue I'm tackling. Initially the issue was with images stored in the database, but I resolved that with setting custom URL extensions. The style sheet we have in the database is returning a 404, so the entire site is without style.
I did some digging, and found the following:
While we were using ~/CMSPages/GetCSS.aspx in V8.2, that appears to have been deprecated/obsolete for some time now. The CSS references in the master page all point to ~/CMSPages/GetCSS.aspx.
In V8.2, I can confirm the presence of ~/CMSPages/GetResource.ashx, but that appears to be missing after the V9.0 upgrade. I installed a blank template site as well to confirm, and it's not there either. I verified I am using the latest upgrade package. I had already hit an issue with the pre-12/15 edition.
The V8.2 ~/CMSPages/GetResource.ashx does not work in a V9.0 as the API for CMS.UIControls no longer contains the ResourceHandler class (which is also used in ~/CMSPages/GetCSS.aspx).
I can confirm in the V8.2 codebase that ~/CMSPages/GetResource.ashx works, returning the specified stylesheet.
TL;DR - Upgrading from V8.2 to V9.0, I appear to be missing ~/CMSPages/GetResource.ashx, and am not sure where it got off to.
Environment Information
Test Server: Windows Server 2008R2 SP1 on IIS 7.5 w/ .NET 4.5.2, MSSQL 2008R2 Database backend
Dev Server: Windows 8.1 with IIS 8.5, VS 2015 and MSSQL 2008R2
Kentico V8.2 Site in Portal Mode
I appreciate any ideas you have.
Thanks!
Most of the .ashx were moved to the CMS.UIControls assembly and adjusted to implement IHttpHandler.
This way the handlers can be used by any application that references the Kentico libraries, specifically the UIControls. This approach has been utilized e.g. in the new MVC support in Kentico 9.
If you need to customize the handlers you can take advantage of the GetFileHandler and AdvancedGetFileHandler abstract classes implementing IHttpHandler.
I was receiving a 404 on GetResource.ashx in v8 when deploying my site. I have my site setup as a web application. My problem was I was only deploying CMSApp using Visual Studio. I needed to also deploy CMSApp_AppCode. https://docs.kentico.com/display/K81/Publishing+web+application+projects+from+Visual+Studio
when I upgraded to v9 from v8.2 I was getting a 500 Error on GetResource.ashx. After my upgrade I just re-deployed. I don't know what the issue was, but getting the errors, I cleared out all the files on the Azure server then deployed. This fixed my error.
Maybe one of these two items will help you.
If I read the release notes correctly, they moved the files to the UIControls library and you can still utilize the old references without issue. I've upgraded my website from 8.0.48 to 9.0.1 and 9.0.4 and had no issues. In fact, I still use the /CMSPages/GetResource.ashx?scriptfile=/path/to/file.js I believe the change was specifically to accommodate the MVC model.
Related
There was an error in the working CMS and I can not even enter management panel. I did not update PHP on the server, nothing changed in the configuration, and yet I can't enter the administration panel or display the WWW page.
When I try to get on administration panel or on website there is a message like this:
PHP Runtime Notice: Declaration of tx_ttnews_catmenu::wrapTitle() should be compatible with t3lib_treeView::wrapTitle($title, $row, $bank = 0) in /home2/izbampro/public_html/typo3/typo3conf/ext/tt_news/class.tx_ttnews_catmenu.php line 56
Is this a bug related to a too old version of PHP, or could someone break into the server and change the configuration?I have no idea what could have happened, everything worked well several days ago. Please help me with this error.
what do you mean with the administration panel?
in TYPO3 you have the BackEnd where you can do the normal administration and editorial tasks.
it is called normally with domain.tld/typo3/
the other area for administrative tasks is the Install Tool
which is called with domain.tld/typo3/install/
While the Backendneeds a running TYPO3 instance the InstallTool should be callable even if there is no configuration (e.g. database).
regarding your TYPO3 version:
we can guess a little bit with your data:
PHP 5.6.26 will let run TYPO3 only until version 7.6
the function reference t3lib_treeView::wrapTitle will restrict the version in the same way as the classname was available in core up to 4.7. for later version there existed an compatibility extension, first in core, later from TER.
if you have a look onto your server we might have further restrictions.
I will not exclude the usage of older versions up to 4.7:
these versions can be identified by files typo3conf/localconf.php, while since 6.0 the files are named typo3conf/LocalConfiguration.php.
In the same way there is a break in the storing which extensions are active in your installation:
up to 4.7 it was one line in typo3conf/localconf.php, since 6.0 it is an own file typo3conf/PackageStates.php.
You should be able to call the install tool, which will show the version (a screenshot from the appearance after the Install Tool login might help. But first we need to make you accessing the Install Tool.
Are you able to login to the install tool?
the TYPO3 version will decide about the next steps
I'm having difficulty in integrating AEM 5.6.1 with Site Catalyst. It allows me to connect in the configuration successfully, but does not work on the framework setup.
I've followed the standard procedure to connect AEM to SC and it accepts my login in the configuration, but fails on the framework set up with the browser message 'We were not able to login to SiteCatalyst. Please check your credentials and try again.'. Behind the scenes in the server log;
12.12.2014 14:10:06.967 *WARN* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.SitecatalystHttpClientImpl Data center 'https://api3.omniture.com/admin/1.3/rest/' responded with errors {"error":{"code":500,"message":"Internal Server Error"}}
12.12.2014 14:10:06.967 *ERROR* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.servlets.SitecatalystServlet Call to SiteCatalyst method 'Company.GetReportSuites' failed com.day.cq.analytics.sitecatalyst.SitecatalystException: not authenticated
I've tried accessing via the API Explorer and it works.
I've tried the troubleshooting guide without success.
I can log in to Site Catalyst, I'm an admin, I am in the web services access group.
I've tried using a clean install of CQ5.6.1 with geometrixx - it doesn't work either.
I've tried this from a server and from a localhost/dev machine with the same results. No proxy. I've even tried using the shared secret as the password but then it doesn't connect at all, and fails on the configuration screen.
What might cause this to fail?
If it doesn't work with a fresh install and Geometrixx, then it's probably an Adobe bug. That's typically the first thing support will ask you about.
I would also verify using Geometrixx Outdoors, or a more recent demo site, on your fresh install, just to ensure it's not an outdated ClientLib issue.
I know this isn't a direct answer to your question, but honestly, I would approach the integration differently. I've worked with the AEM-SC framework and it's buggy at best. It's very finicky, it doesn't REALLY work the way the documentation claims, and it requires that you're very specific about what Clientlibs are on the page.
Moving forward, I think using Adobe Dynamic Tag Manager is the better approach, for many reasons. My understanding is that it's Adobe's recommendation as well. I'd consider moving to that. In AEM 5.6.1, you'll have to customize your integration with DTM, but it's not very hard.
Solution: Add a property on the configuration node for sitecatalyst: (eg. /etc/cloudservices/sitecatalyst/my-sc-configuration)
server=https://api.omniture.com/admin/1.2/rest/
it also seems to work with newer API versions such as https://api3.omniture.com/admin/1.3/rest/
It would appear that for 5.6.1 it ignores the OSGi configuration, at least for the configuration screens. With this extra property, the framework page loads without error and allows selection of the RSID.
Friends Initially there was problem in the re installation of VS 2010 in my computer with Xp.
But i was able to install recently and every thing goes fine. I was able to use MVC 2 and other features. But when i tried to install MVC 3 i could not get success.THe installation process Roll back giving the message of FATAL ERROR DURING INSTALLATION.
Then i check in the error and found that Microsoft ASP.NET webpages 1.0 was missing in my computer.Is that the problem for installing MVC 3? or other .
I have attached the screen shot of error. I will be thankful for the solution.
Sorry, i couldn't upload clear picture.But Error shown was as follows:
Returning IDOK, InstallMessage_error[This product Requires Microsoft Asp.net web Pages 1.0. Please install the missing component, then try to install this product again.]
strong text
Using the Web Platform Installer will probably be the easiest way for you to solve your dependency installation problems. Using the installer will give you the ability to select and download/install a variety of products. For instance take a look at the follow screen shot:
Under the Products tab, you have the ability to select MVC3, ASP.NET web pages, MVC3 Updates, etc. Since some products depend upon others the Web Platform Installer will also manage these dependencies for you when installing your selected items.
Good luck, and hope this helps you some.
Where can I find information about upgrading Magento Enterprise 1.7. to the latest 1.9. ?
There's no such documentation.
Your general approach:
1. Close production server
2. Backup all DBs and Magento installation
3. Turn off all your custom extensions and themes
4. Delete from HDD: core Magento modules, their layouts, all standard themes and cache.
5. Get 1.9 EE, copy it over your installation
6. Request Magento through http
7. Walk at your site, notice errors and warnings, fix them
8. Check documentation and update for your theme, whether it supports EE 1.9. Turn it on if it supports, otherwise you'll need another theme.
9. Check documentation and updates for all your custom extensions - whether they support 1.9. Turn them on - one by one.
You won't have any problem with upgrading all core DB data - it's made automatically.
You'll have problems with your custom theme, as you'll need new version with support for 1.9. And you'll need to check your custom extensions and upgrade their source and DB data to fit 1.9.
Generally all Magento upgrades work by running the updated code with the old database. The differences will be detected and incorporated automatically on the next page request. Magento keeps track of every module's version number for this reason.
Because there is a chance some modification will break it is best to do this on a new (temporary) site then add the modifications back in gradually. That way the old site is still active and uninterrupted.
I think there is no official documentation. The best way is to figure out what core functionality is used in your customizations and after that look at theirs realization in new version: does it changed or not.
To know what was changed in new version you could check changeslist
I have a DNN site (5.06) that I developed on a standalone machine running IIS7. When I copied the site to the production machine running IIS6 and enter the URL, such as www.site.com, I get a generic DNN error page with no additional information. However, if I add the default page, www.site.com/Default.aspx everything works fine.
The Friendly URL settings were never changed and I've verified Default.aspx is entered on the Documents tab in IIS6. The portal event viewer has no entry for the error page I get.
I'm nearly certain it has to do with migrating from IIS7 to II6; clearly I'm missing something here. Any ideas?
DNN has confirmed this is an error in 5.06, and will be addressed in a future update. That doesn't help me today, but I was able to work around the problem by adding the following to the Friendly URLs list:
Look for: .*/
Send To: ~/Default.aspx
I can't find the forum thread I was reading yesterday, but did find this one which also goes into detail on the issue: Error upgrading from 5.5.1 to 5.6.0
Pretty odd...
Double check PortalAlias table in your SQL server. Confirm www.site.com is in there.
Double check host headers in IIS6 has www.site.com
Make sure Default.aspx is in the documents area of IIS6 and set as the top default to run
Recycle your app pool
cross your fingers
Only thing I ever run into from IIS6 and IIS7 is in the app pool running in Integrated mode or classic... but that is usually as issue going from IIS6 to 7, not vice versa.
I was able to fix the issue (for me) by taking the web.config file from a working site with the same version of DotNetNuke and modifying it to have the correct machine key and connection strings. This is my last resort when DotNetNuke is being strange. I am running 10+ DNN sites at version 5.6.0 and I only encountered this issue once.