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.]
Related
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).
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 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.
While there are some similar posts about this issue, none seem to fit my problem exactly, so I would like to ask if anyone knows what I am doing wrong.
I am trying to run a PHP web application that I created in Netbeans. I am using Glassfish 3.1.1 as the web server. Whenever I run the application through Netbeans (by selecting the project, right clicking to get the context menu, then selecting "Run"), my browser opens to what I believe to be the correct url, but all I get is a 404 error page stating the following:
type: Status report
message:
description:The requested resource () is not available.
Am I missing some crucial configuration step?
I have checked my hosts file and it contains the entry:
127.0.0.1 localhost
Is there something else I need to do?
I have PHP 5.3.8 installed and all php commands run from the command line.
Would it be something in the php.ini file that needs to be configured?
I am stumped. Any help would be greatly appreciated.
ANSWERED
Please accept the comment below from Jonathan Spooner as the correct answer.
Just install Quercus within GlassFish 3.x and you can run PHP and Java.
As I stated in the comments, GlassFish and Apache Tomcat are Java application servers. In order to serve PHP pages you'll need to install a web server such as Apache HTTP web server. You'll also need to configure Apache to serve PHP files.
Something that you might look into is WAMP (Windows/Apache/MySql/PHP). This offers a simple way to get up and running quickly with little to no configuration.
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.