I searching for a Solution, how can i outsource the TYPO3 site config.yaml file in my own Extension?
thanks for help!
You can do this by doing import statements in the config.yaml of the site.
Like this in config/sites/main/config.yaml:
imports:
- { resource: 'EXT:site_mysite/Configuration/Sites/my_site_config.yaml' }
In our cases a typical yaml configuration for the site looks like this:
imports:
- { resource: 'EXT:site_myproject/Configuration/Sites/defaults.yaml' }
rootPageId: 401
... domains
... error handling
We move everything that does not contain a Page ID (root page ID; error handling) into the site extension, to make the site extension re-usable (= language configuration or route enhancers are moved to the site extension)
Related
There are guides and questions all over the place on how to do this, but never really a concrete answer that is satisfactory. Basically, I'm wondering if it's possible to host a static SPA (HTML/CSS/JS) in GCP Cloud Storage.
The main caveat of this is that the SPA has its own routing system (ReactRouter) so I want all paths to be served by index.html.
Most guides will tell you to set the ErrorDocument to index.html instead of 404.html. While this is a clever hack, it causes the site's HTTP response code to be 404 which is a disaster for SEO or monitoring tools. So that will work, as long as I can change the response code.
Is there any way to make this work? I have CloudFlare up and running too but from what I can tell there are no ways to trim the path or change the response status from there.
A good approach here is to use Google App Engine to host a static SPA. https://cloud.google.com/appengine/docs/standard/python/getting-started/hosting-a-static-website
You can use the app.yaml file to map urls to the static file. Here’s an example:
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /
static_files: www/index.html
upload: www/index.html
- url: /(.*)
static_files: www/\1
upload: www/(.*)
Documentation for app.yaml https://cloud.google.com/appengine/docs/standard/python/config/appref
One way to circumvent the problem is to use server-side rendering. In SSR all client requests are passed to a backend app so there's no need for a Cloud Storage-hosted index.html.
This of course comes with its own set of complications but we're avoiding the above-mentioned 404 hack or resorting to any further dependencies like App Engine.
Alternatively you could go with hash-based routing, i.e. paths like https://example.com/#some-path.
A very simple solution would be to just add the index.html file as the 404 fallback. This will always route everything to your single page app.
If you use Cloudflare, you can use a Cloudflare Worker to override the 404 status code, which comes from the Google Cloud Storage error page.
The code for the Worker should look like this:
addEventListener('fetch', event => {
event.respondWith(fetchAndLog(event.request))
})
async function fetchAndLog(req) {
const res = await fetch(req)
console.log('req', res.status, req.url)
if (res.status === 404 && req.method === 'GET') {
console.log('overwrite status', req.url)
return new Response(res.body, {
headers: res.headers,
status: 200
})
}
return res
}
I found it here in the Cloudflare community.
Using TYPO3 6.1.9 (will be updated soon to latest 6.2).
Is it currently possible to use a FAL storage with another domain? The webspace looks like this:
path-to-web-directories/
- maindomain.com/
- - fileadmin/
- - typo3/
- sub.domain.com/
- - files.txt
In the TYPO3 backend I created a file storage for the directories path-to-web-directories/maindomain.com/fileadmin/ and one for path-to-web-directories/sub.domain.com/. This is really great and work so far. I can manage the files in both storages.
But now if I set a link to a file located in sub.domain.com, the URL looks like this:
http://www.maindomain.com/sub.domain.com/files.txt
instead of
http://sub.domain.com/files.txt
Ist this issue a part of TYPO3 or can I configure this with realUrl (which I'm using)? And how can I do this?
I resolved the problem:
The URL is generated in the class TYPO3\CMS\Core\Resource\Driver\LocalDriver->getPublicUrl
In this case an own extension with a new resource driver is needed.
I Have an issue where the following code works when run in Visual Studio however I get a "The resource cannot be found." error when I deploy to the test server.
The JavaScript:
var form = document.forms[0];
form.action = '/NCR/CreateSaveNCR';
form.submit();
The Controller Code:
[HttpPost]
public ActionResult CreateSaveNCR(viewModels.NCRCreateViewModel model)
I have no idea what the issue is. Thanks..
if the resource cannot be found, and the code is identical, then it might be a path issue, is the web address http://yourdomain.com/NCR/CreateSaveNCR? or is it in a folder underneath that? You also might (uncommonly) have to restart the IIS process to get it to take in new routing info (rerun global.asax's app_start).
If you deploy to a virtual directory it will need to be included as part of the mvc url path.
Another possibility is that the file exists in the directory in dev but is not included as a project file and is left out of the "publish" deployment method if you push changes to your staging environment using that mechanism.
Never hardcode urls. Always use url helpers when dealing with urls:
form.action = '<%= Url.Action("CreateSaveNCR", "NCR") %>';
I am using the Zend Framework for construction of my site, which uses the application.ini file to store database info (such as username and password). I discovered that typing /application/configs/application.ini in the web browser plainly shows all the contents of the applications.ini file.
How can I prevent this? I tried setting the chmod public access to nothing, but then the website couldn't function anymore because of access rights. Anyone familiar with this?
Your document root setting in your web server configuration should point to the subdirectory that has your index.php in it, not the top-level directory of the whole application install.
E.g., you have something like:
myapp/application/Bootstrap.php
myapp/application/configs/application.ini
myapp/application/controllers/...
myapp/application/views/...
myapp/library/...
myapp/tests/...
myapp/public/index.php
Set your document_root to myapp/public and not myapp.
I solved this problem by writing the following in the .htaccess file:
<Files application.ini>
order allow,deny
deny from all
</Files>
If you don't have access to change your document root and you are using the Apache web server, the "quick and dirty" approach might be to create a ".htaccess" file with the following contents, created in:
/application/configs
Contents:
deny from all
I have setup TYPO3 successfully on my local server. But I am having problem when clicking on any menu item: It's showing "url not found on server".
When I type in the URL manually into the browser it shows the page. It's only having problems when redirecting after clicking on a page item at any frontend website page.
That might be related to the domain config or RealURL... or both ;)
Do you use RealURL? Or do you use the standard url config?
If links to sub pages look like index.php?id=12345 you are using the standard config.
My guess is that the local DNS ("hosts file") is not configured correctly.
With the hosts file you can simulate how the web site will appear when it's online, hooked up to a "real/global" DNS. (Not quite, but in a nutshell)
So if you set up Typo3 to be reached under http://www.example.com/ you need to tell your local DNS ("hosts file") to route a request to http://www.example.com/ to your local host e.g. http://127.0.0.1/ . In that case your host file needs an entry like so:
127.0.0.1 http://www.example.com/
What Domain do you enter to reach your web site? Where do the links from the menu link to?
If you wanna know mor about the "hosts file" look here:
http://accs-net.com/hosts/how_to_use_hosts.html
If you can log in into the TYPO3 backend (/typo3/) and can access the frondend through /index.php, but not through the generated menu links, then RewriteRules for mod_rewrite don't apply.
Usually TYPO3's installer should detect this configuration and disable RealURL, which is responsible for generating such nice looking URLs (instead of index.php?id=123). It seems like this failed (or you copied everything afterwards without the .htaccess file?).
Make sure that you have TYPO3's .htaccess file in place in the root directory of your installation. If this is the case, make sure that mod_rewrite is enabled in your Apache config.