I am not very experienced in Typo3 so I hope my question/problem would be a quite simple one.
I use a Typo3 9.5.0 LTS instanz on Ubuntu with Apache and MySQL.
Problem is that URLS routing (https://typo3.org/community/teams/typo3-development/initiatives/routing/) is not working.
I created a Site Configuration for relevant Pagetree. Within the pages in Backend the URL segment is visible and changeable. This URL segment is also taken correct by menu entries and by the sitemap.
But I could not access the pages with that path (get 404).
to summarize:
/index.php?id=[URL Segment] works fine.
/index.php?id=[ID#] works fine.
/[URL Segment] does not work. Apache creates 404
I have no routeenhacers in yaml site config active and cleared already the cache.
It would be great if someone has an idea where to dig deeper to solve that issue.
Thanks
yES
Related
I'm currently using Google Appengine to host a website with Golang as the backend. I have a custom domain setup and (sometimes) it works perfectly fine. My website requires some css and js files from the server. These were served perfectly in the past but now it randomly stops working. Both on the "mydomain.de" and on the "myapp.appspot.com" domains. Sometimes it works on the normal domain and then it works on the other and sometimes even on both. But if I reload the site after a couple of minutes it just shows me an old index.html file (that I have removed days ago).
Did someone experience this problem in the past and does anyone know a fix for this?
Thanks in advance.
Have you ruled out your browser cache as the source of the problem? If after getting a stale version, shift-reload (assuming Chrome or Firefox) brings up the desired version, then look into how to do "cache busting" for css and js, and check the app.yaml doc for how to set expiration times on static assets (assuming your index.html is static).
Ok, somehow I am serving ads in my NodeJS / AngularJS application, but I haven't include this myself.
There's some package or included link sending ads to the client, but the ads are not visible, and the adserve url changes with every request. (The url that can be seen in the screenshot below)
How do I find out which place in my application serves these ads?
PS: I am sure this doesn't come from my local dev pc, my other collegues have this issue as well.
A quick trick may be to search for the url in every files of your repository. If you use a cdn to load your librairies, try to look inside also (you can do that directly in chrome dev tool with ctrl/cmd f in the sources tab).
Hope it will help !
The "adserver" in my project turns out to be a tracking / analytics beacon included by the Realtime.co framework.
Thankfully, the author responded to my email very quickly, and they also provide a beacon-free version of their framework. So problem solved :)
I am not able to set Ajax-Solr on my system.I did a bit of R&D on Ajax-Solr for the same .
I understood what it tries to do with the tutorial provided at https://github.com/evolvingweb/ajax-solr/ , but unfortunately, I am not able to able to set it up on my system.
I dont know how to integrate it with Solr. Into which directory of Solr instance does Ajax-Solr goes?(I know it doesn't matter where Ajax-Solr folder is kept but still just to to be sure)
I changed my solrURL to "http://localhost:8080/solr/" in reuters.js file.But still when i browse to "http://localhost:8080/solr/", it still shows the same backend Solr UI. (This may sound a kinda noobish)
Can you please suggest me how to get the Ajax-Solr front end UI ??
Please suggest something.
Thanks
Regards
ajax-solr is just HTML, CSS, and JS. You can open the demo index.html from your harddrive in a browser and it will work (i.e. no webserver!). When you deploy, you can use Apache, Nginx, Tomcat, whatever. If you can make your webserver display an HTML file, you can make it display HTML files that include the ajax-solr JS files.
You have to deploy the Ajax-solr web application either on jetty or on some web server or app server.
If you want to deploy this in jetty, you have to create a WAR file out of th. S reuters sample.
If you have Apache on your machine, you can copy this to the htdocs folder, for eg.
As the title of my question states I am having trouble with my MediaWiki 1.19.0.
I'm running apache2 and I have a few sites that are working fine. I downloaded and installed MediaWiki 1.19.0 and so far it works fine.
But if I try viewing my wiki page from another computer or over the internet the styles and skins don't display.
Any help would be appreciated.
You need to yet yourself Firebug and find out with it which styles/scripts HTTP requests are failing.
I was having this exact same problem. The load.php entry was not being created in the conf.d/mediawiki119.conf file. It also wasn't creating the symlink from /var/www/mediawiki119/load.php to /user/share/mediawiki119/load.php.
Once you fix those two things it will work.
load.php was a new feature that loads the skins which is probably why they forgot it in some of the configuration files.
Im using smartGWT v2.1 with GWT 2 and Appengine SDK 1.3.0
On localhost, everything works fine!
When I deploy everything goes fine too, without any error!
The problem is, when i access the the app it returns an blank screen. Using the firebug i saw just nocache.js missing.
ErrorLog:
GET mika.nocache.js
http://perfworker.appspot.com/Mika/mika.nocache.js
404 Not Found
perfworker.appspot.com
Just to know, the last version of smartGWT should work on AppEngine out of the box?
Thanks in advance!
Cleber
I'm going to guess you're developing on Windows. NTFS, unlike nearly every other filesystem, is case-insensitive, so it'll work fine if your file or directory has one capitalization and you're accessing it with another. On every other platform, however, including the one App Engine runs on, capitalization matters: Check that you're using the same capitalization to access the file as is used to name the file.
Btw, this not only applies to SmartGwt, but to any GWT app. I would have voted on the answer above, but I don't have enough rep points yet [new user]. Changing the casing of the link in the base html page worked for me.