Hot answers tagged

6

Currently, Element API is hard coded to throw a 404 exception for single element endpoints, if the element criteria returns no results. There's no way to prevent this exception, add "fallback" criteria or to display an error message. Note that the 404 exception will only be thrown if the first parameter is set to true, though. If it isn't, Element API will ...


5

The .htaccess file was missing the period in the filename when initially installed.


5

You can simply create a 'robots.txt' file in your templates folder and populate it using twig (templates do not need to end in .twig). Not sure what you're trying to control exactly, but something like this should technically work. User-agent: * {% set entries = craft.entries.limit(null) %} {% for entry in entries %} Disallow: {{ entry.uri }} {% endfor ...


5

99% chance that it is because the .htaccess file did not come over when you copied the files, as it is a hidden file. Copy that over to your new webroot and those interior pages should properly work.


5

Turns out the general.php file had the following line (docs) in it: 'errorTemplatePrefix' => "_errors/" Once I'd created the proper folder and files, all worked as expected. Thanks, @CraftCMS Twitter person!


4

Have you got your htaccess file working ok? By default the htaccess file is named incorrectly, it should be .htaccess nothtaccess`. You can read about renaming that file in the installation docs. As a quick test you could try: "/index.php/new-url" If that works it's your htaccess file.


4

Not currently, but I agree it's kind of annoying. I thought maybe you could pull it off with a plugin since Yii does have an onException event, but there wouldn't be a way to disable logging of 404's without some code changes on our end. I've added it to our 3.0 list to add a config setting to disable logging of 404's though.


4

When your plugin has a camel cased name you need to make sure you camel case your references to it, such as when you try and visit an action url. I assume this is due to when craft tries to resolve the url it sees pluginname and pluginName as two different things, much like php variables. I would also assume this is due to the way Craft autoloads classes. ...


4

Figured it out. I assumed that my assets folder needed 744 just as the install instructions mentioned for the Craft CMS folders. But, I need to change the permissions to the standard 755. Once I did, I could view the images.


4

It's quite possible that you are in Dev mode. If you switch to false, the 404.html may then be recognized… Look at general.php, then change devMode to false. // Dev environment settings 'dev' => [ 'devMode' => true, ],


4

404 isn’t a valid redirect status code, which is why {% redirect '/' 404 %} isn’t working correctly. It sounds like you want to: first issue a 301 or 302 redirect to the homepage then serve the homepage, but with a 404 status If I’m understanding you correctly, even if you could pull it off (maybe doable with a query string or something stored on the ...


4

Craft 3 action routes are snake-case rather than camelCase thus your route needs to be plugin-handle/controller-handle/function-name instead of pluginHandle/controllerName/functionName Your Controllers namespace must be prefix\namespace\name\controllers so in your case it could be kr37\drycalendar\controllers not Craft. Furthermore you don't need to ...


4

I pondered this for a while, and then did this, which will direct us to specific entries (not templates, I don't want to create more of those): {# We need a unique 404 for each site - just take us to the right slug relative to current URL #} {% switch currentSite.id %} {# siteA.com #} {% case 1 %} {% redirect '/my-404-slug' %} {# siteB.com #} {% ...


3

Where are the links coming from? A Template? "?p=1504" should not 404, if it's attached to the end of an existing "200" url. Do a crawl with an app called "Screaming Frog" to determine where your 404s are actually coming from then you can fix in your templates. Sounds like your just sweeping the actual problem under the carpet and not fixing the source ...


3

I was being silly here. We have separate folder for all frontend assets (including twig templates), which will be copied over to the craft folder on build. The target files are gitignored and need to be force add to git. I added the files under web but missed out on the craft/templates folder.


3

Just had a similar issue with a colleague. Double check your folder permissions. It might be the case that Craft isn’t allowed to write the transformed files to your assets folder. Something like chmod -R 777 public/assets might do the trick. (You might want set this to something other than 777 if it worked out. Look at the docs for details.)


3

It turns out this is an nginx problem. This post describes it: The troubling part of the nginx configuration looks like this location = /robots.txt { access_log off; log_not_found off; } What’s inside isn’t the problem. It’s pretty basic, whether found (access_log) or not (log_not_found) don’t log it ( off;). The problem is with ...


3

Looking at your screenshots, the host names are different. The cPanel 404 shows mysphotos instead of myphotos. Probably a typo somewhere in your templates.


3

The reason you're getting a 404 is because Craft isn't even hitting your help/_entry.html template. Because there's no entry matching the URI /help/asdf, the template will never render and the request will go straight to 404. The solution is to create a dynamic route matching your section's URL format (i.e. help/<slug>), and point it to the same ...


3

I had the same issue on my mac and struggled for hours. Having the right .htaccess file in place was key, but if you are not getting Craft's error messages, that's a sign your .htaccess file is not having any effect (you can verify this by placing some random text in there and see if you get an internal server error or not). Making the following changes to ...


3

I don't have specific answers to your questions, but that's mainly because I feel there are some clarifications and observations that I think might be more helpful. The thread you linked to is referring to template caching using the Craft {% cache %} tag in a template. All of its cached data is stored in the database in the craft_templatecache* tables, not ...


3

These are very likely bots that are scanning the website for various things (I see it for WordPress logins a ton). Two things you can do: Redirect them. This is what I do for WordPress bots Install the Retour plugin to get a better overview of what 404 errors happen on your site.


3

There's a long discussion of all of this in the Handling Errors Gracefully in Craft CMS article, if it helps.


3

Craft will serve one of 3 types of 404 errors. When Dev Mode is enabled, you will get something like this, which shows the full stack trace leading up to the NotFoundHttpException: If this looks like what you’re getting, then Dev Mode is definitely enabled. Double-check config/general.php for devMode, or web/index.php for YII_DEBUG. Otherwise, you will ...


3

If you've set devMode to false in your local environment and you still can't see your 404 template, go to your own user account in the CMS and uncheck "Show full exception views when Dev Mode is disabled".


3

If devMode is on, you will always see the above exception page. Turn it off to see your 404 page, or just navigate directly to the template, e.g. http://example.com/404 More here: https://nystudio107.com/blog/handling-errors-gracefully-in-craft-cms#handling-exceptions-on-the-frontend


2

So I figured it out! my htaccess did not have the "." in front of them. So my htaccess in my subdirectory was not being read. Once I renamed it to .htaccess, it worked fine!


2

When a connection to the database can't be made Craft throws a 404. This sound like it might be your problem because you say it happens intermittently.


2

I don't think you can open a .ico file with the browser directly, that's why the request 404s. There's two ways to make it do its thing: simply place it in the web root, e.g. public/favicon.ico use this link tag in your document head: <link rel="icon" href="{{ url('dist/img/favicon.ico') }}" type="image/x-icon">


Only top voted, non community-wiki answers of a minimum length are eligible