ISPConfig (Management Panel)
We have two versions of PHP: 7.2 and 7.4. They work properly. However, in the site edit form, in the PHP version selection list, option 7.4 is always displayed. Even if version 7.2 is set, re-entering the form shows version 7.4. In this case, the website works properly on version 7.2. The error of displaying the PHP version in the form is bothersome, because every time you change the site, you have to be careful to change the PHP version as well. Sometimes, unfortunately, you just have to find what version it is.
How can this error be fixed?
Other than the tag, your question does not clearly indicate which software you are using.
Luckily I know ISPConfig so your text was hinting to the question being about that and the tag confirmed it.
I suspect you are editing the site as a client, not a admin, and you have Client protection enabled in the main config. Either edit the site as admin, or disable client protection (Login as admin, go to System, Main config, Client protection).
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 the same problem reported here:
The Doxygen server side search works on my old web site. It does not work on the new web site (new web hosting provider). I've narrowed the problem down somewhat...
The server side search works on original site with PHP version 5.5 and on another site with PHP version 5.3. The new site uses PHP 7.1.
Also, I was able to change one of the sites from 5.5 to 7.1. That caused the Doxygen server side search to fail in the same way. However, the precise reasons are inconclusive, since some PHP extensions are missing in my PHP 7.1 panel. So I have these questions:
What versions of PHP is Doxygen's server side search expected to work with?
Are there any PHP extensions that Doxygen's server side search depends on?
[Questions to which I can find no answers in Doxygen documentation nor on it's mailing lists and such.]
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.
I can't access my prestashop admin page (in localhost)?
When I enter into this page, it's shows this error!
How to fix this problem? Please help me.
Prestashop changes its admin folder to something like admin12fsg7wghdfgf. You need to go to folder where you installed prestashop and find that folder. And after that you could enter backend side by link similar to this http://localhost/prestashop/adminwt3452sdg
I had the same problem.
I even deactivate the antivirus and nothing fixed the problem.
Then what I did is to install the eCommerce in a Cpanel and over there all worked perfectly.
It's caused perhaps because Prestashop is tracking urls for his product's installations and of course this doesn't work in localhost...
I had a problem and it became alright after I downgraded the PHP version to the one recommended by Prestashop for the relevant version.
In my case, the PHP version was 7.2 and Prestashop 1.6. The admin page did not open, 500 Error.
I lowered the PHP version to 5.6. May be upto 7.0 it accepts.
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.