Hot answers tagged

7

On recent Ubuntu systems (for sure on 14.04), mod_rewrite is installed but not enabled within Apache. You may just need to enable the rewrite module and restart Apache. $ sudo a2enmod rewrite $ sudo service apache2 restart


7

There are a few plugins which can handle this, but Retour is the newest and shiniest! https://github.com/nystudio107/retour It's from the same developer as SEOmatic... he puts a lot of love & attention into his plugins, so you know it's safe to rely on.


6

Craft has a twig redirect tag. You should be able to create a "redirect" template that handles redirects based on {slug} and/or url segments and then use Craft routes to direct "legacy-subdirectory" requests to your redirect template. I have not tested this.


6

This looks like a problem with your DocumentRoot config option. If you have access to your Apache VirtualHost configuration, you should append /public to your DocumentRoot. If you're configuring the host via some kind of control panel (i.e. via your web host), look for an option like "Web Root," and add the same /public path. So, if your current ...


6

Putting aside Craft for a moment, it's not just Craft, you'll usually end up throwing more things on a web server as time goes by. If those scripts/apps are expecting an .htaccess file and you're using nginx, you have to do some extra work to get those rewrite rules or additional pieces of magic working. As someone who cut his teeth on Apache, I've swung ...


6

There is no "this over that" for Craft specifically. Your own statement "it depends" plays a big role. I would read this pretty extensive post on DigitalOcean "Apache vs Nginx: Practical Considerations" as a good start on what software to use. https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations For me personally this ...


5

It turns out that I was running a dev release of PHP 5.6 from a PPA and not the official Ubuntu release. With Brad Bell's help (thank you so much!) I got on the right track to looking into PHP and realized that that was the problem. After purging the PPA and reverting to PHP 5.5.9 on the official Ubuntu repo, the problem seems to have gone away. Hopefully ...


5

You can't use the domain .dev anymore, it's Google's gTLD (https://icannwiki.org/.dev) and they don't want to share. See https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd for a detailed backstory. Instead, you should use the TLDs reserved by the IETF for this purpose, like .test. For reference, this is the HSTS List maintained by ...


5

It turned out that the problem was from customizing the domain's document root in the userdata files and then the PHP-FPM configuration had not been rebuilt and the service not restarted. The following resolved the issue: /scripts/php_fpm_config --rebuild /scripts/restartsrv_apache_php_fpm It's interesting since there are a broad variety of issue that ...


4

TL;DR: Turns out this was an issue with my apache config on the Craft instance. Explanation: I did a little digging around the GuestEntriesController.php file and noticed that Craft was not picking up that my POST was coming from an ajax request. After looking into that more I manually added the ajax header to my post request: $.ajax({ url: config....


4

After checking out the craft/app/etc folder, I noticed the cache folder was missing. It turns out that the problem was with my FTP client ignoring folders named "cache". So really a dumb mistake on my part. Thanks for your help @BradBell!


4

The solution I came to was creating an Origin Certificate on Cloudflare, installing on it on my VPS, and setting the SSL setting to Full Strict. Now admin assets are loading perfectly over https. No .htaccess or Patrol plugin required. If someone knows more about why this worked and the previous approach didn't I would love to hear your thoughts. Thanks @...


4

Been using this one for years, works great: <IfModule mod_rewrite.c> RewriteEngine On # ========================================= # # Force website to use "www" RewriteCond %{HTTP_HOST} ^example.com [NC] RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301] # ========================================= # # =================...


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

Since you mentioned in an earlier post that you are performance-minded, this might interest you: Stop using .htaccess files! No, really.


3

Apache is generally hosted on Linux which the vast majority of web hosting services use. IIS is Microsofts platform and is much more difficult to set up as well as less common with hosting providers. Just use Apache.


2

Looks like the .htaccess file included with Craft is not being read or you didn't rename it (should be .htaccess with the period at the beginning). That's why /index.php/admin is working but /admin/ is not. One other possibility is Apache is setup to ignore .htaccess files. If that's the case, add this to your httpd-vhosts.conf file. <Directory "C:\...


2

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 ...


2

As Brad Bell pointed out in a comment that you should use index.php, it might have something to do with your .htaccess and general.php Your .htaccess File should look something similair to this: <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / # Send would-be 404 requests to Craft RewriteCond %{REQUEST_FILENAME} !-f ...


2

I have found the solution within the answered question: omitScriptNameInUrls is not working 'sudo a2enmod rewrite' was needed! Thanks all.


2

Oh, I am blind. Rather than delete this embarrassment, I will post this mea culpa for anyone else that may experience a similar brain fart. I had subconsciously typed the directories in html/ using the common POSIX/ISO standard without realising it, so html\en_US\. Of course, this works on OS X because the OS is case insensitive by default, and does not on ...


2

This is solved by this thread. The common thread here is Rackspace Cloud Sites, which apparently needs a RewriteBase / instruction in .htaccess. Thanks @maxx and @christopher-healey


2

I solved it. I needed to remove calls to 'server' and 'http' in my enginx_app.conf file. Now the file only makes calls to 'location'.


2

So... just to be clear. This /style.css is a static asset, it's not sitting in the craft/templates folder, right? Assuming that's the case, something is definitely wrong if https is taking 2 seconds to load it. Sounds like something with your server is misconfigured. How are you measuring this, exactly?


2

IMO, the issue is with this line. SetEnv HTTP_ACCEPT text/html,application/xhtml+xml,application/xml,application/json;q=0.9,*/*;q=0.8 With ACCEPT headers set to a fixed value, it's impossible for Craft 3 to distinguish between Json and HTML requests. This must have been a necessity with the nginx proxy setup. I suggest removing this line from Apache and ...


1

Ok I actually managed to fix this. I moved the index.php file from the cms/public subfolder to public_html and it worked a treat. I had to change the following code: // Path to your craft/ folder $craftPath = '../craft'; to // Path to your craft/ folder $craftPath = 'cms/craft';


1

Think we figured out the root cause of this - we have a load balancer in front of our origin server and, long story short, that load balancer was communicating with our origin server via HTTP, causing the extra http redirect. Fixing that issue would be a long and arduous process so, through some infrastructure updates, we'll be moving away from using the ...


1

Craft's default setting is 'resourceBaseUrl' => '@web/cpresources'. If your site or Docker Container runs http, Craft seems to (correctly) determine the http setup. This is why it ignores your siteUrl / ROOT_SITE_URL. To fix this, either overwrite @web or manually set 'resourceBaseUrl'. Set resourceBaseUrl Explictly set 'resourceBaseUrl' => getenv('...


1

The craft/config/memcache.php file has nothing to do with where PHP sessions are stored. It is for Craft's general purpose data caching. If you want to save PHP session in memcache, you'll need to set the php.ini save_handler and save_path similar to: https://www.digitalocean.com/community/tutorials/how-to-store-php-sessions-in-memcached-on-a-centos-vps ...


1

It's probable that your Site URL in your website's config is using http rather than https. Setting it to https should force the control panel assets to load appropriately. You can change this in Craft's Settings > System > General screen. If you've overriden this in your website's config setting you'll instead need to update the siteUrl setting in ...


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