In fairness, I would first like to say that I have already posted this problem on https://talk.typo3.org/.
TYPO3 version: 10.4.6
Web server: Apache
PHP version: 7.2.10
Database (default): MySQL 5.7.24
Application context: Production
Operating system: Linux 4.19.44-gentoo-mw1
Problem:
Since the update to version 10.4.6 I get for pages to be displayed in the backend:
The requested page is missing a valid site configuration
and in the frontend:
Page Not Found The page did not exist or was inaccessible. Reason: The requested page does not exist
The "View Webpage" button does not respond at all.
I suspect that the TypoScript script no longer fits the latest version. It has not changed since then, but is now making this mistake.
I'm thankful for any help!
Regards, Strawk
'site configuration' is not only typoscript. in former versions you needed a domain record. in newer TYPO3 it is a yaml-configuration.
But you can edit it's content in the Backend without knowing the structur.
There is an BE module SITE MANAGEMENT -> Sites
There you need to configure your domain, language, routing, ...
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).
I have a brand new TYPO3 10.4 install with a bootstrap sitepackage.
My page tree is this
Home
-> Building Management
--> Building Rules
Home shows fine, but all of the lower pages throw a 404 using the speaking url's, even from autogenerated links in the menus. I can still navigate using index.php?id=2, but this is not enabled at all by default.
If I set the language link to /en/ (rather than /) then no pages work, not even the home page.
I built the same site on my development server with the same version of typo3 and the same site package and it works as expected, just not on the production. Any idea where to look for a solution? Here's a pic of the site pagesites-page
The .htaccess was a clue. What appears to have happened is that the .htaccess file was not updated during the TYPO3 install. We copied one from another working install of 10.4.4 and that fixed it. I think there is a step in the install process that checks if there is a .htaccess file, and if there is then it doesn't copy or insert the required changes. Once we copied this across everything worked fine.
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 am trying to change site url from http://localhost/yiiwebsite/backend/web/index.php url to http://localhost/yiiwebsite/admin and http://localhost/yiiwebsite/frontend/web/index.php url to http://localhost/yiiwebsite/.
Can anyone help me to do this.
It's described in official docs here.
Here is some basic info:
The application installed according to the above instructions should
work out of box with either an Apache HTTP server or an Nginx HTTP
server, on Windows, Mac OS X, or Linux running PHP 5.4 or higher. Yii
2.0 is also compatible with facebook's HHVM. However, there are some edge cases where HHVM behaves different than native PHP, so you have
to take some extra care when using HHVM.
On a production server, you may want to configure your Web server so
that the application can be accessed via the URL
http://www.example.com/index.php instead of
http://www.example.com/basic/web/index.php. Such configuration
requires pointing the document root of your Web server to the
basic/web folder. You may also want to hide index.php from the URL, as
described in the Routing and URL Creation section. In this subsection,
you'll learn how to configure your Apache or Nginx server to achieve
these goals.
By setting basic/web as the document root, you also prevent end users
from accessing your private application code and sensitive data files
that are stored in the sibling directories of basic/web. Denying
access to those other folders is a security improvement.
If your application will run in a shared hosting environment where you
do not have permission to modify its Web server configuration, you may
still adjust the structure of your application for better security.
Further configuration depends on chosen web server (Nginx / Apache), which is not even mentioned in the questoin. But both options are covered in official docs by the given link.
For shared hosting environment there is special section too.
And by the way this was asked before many times here on SO, just do a better research.
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.