Q: .htaccess

[mcyzyk]

I have restored a copy of one of my Wordpress sites into (thee awesome!) VVV.

But it's not right. "It's almost as if my .htaccess file is being bypassed."

Apparently, it is! Nginx does not use .htaccess.

And yet, .htaccess is crucial to Wordpress.

Not sure what to do. Is there any way to get .htaccess to be recognized/executed in a VVV environment?

Thanks,

Mark

[tomjn]

HTAccess is an Apache specific feature. Lots of WordPress sites don't use HTAccess or Apache, it is not crucial to WordPress.

Ideally it wouldn't be crucial for your site either, but without knowing what you use it for it's difficult to suggest alternatives or solutions. Do you have more information about what you need it for and what you're trying to achieve with it?

[tomjn]

As for:

Not sure what to do. Is there any way to get .htaccess to be recognized/executed in a VVV environment?

You could install Apache, but it would mean forking and maintaining your own VVV, a massive undertaking. It would be orders of magnitude easier to work around it so that your site works on any server be that Apache, Nginx, or even others. A lot of the features people use HTAccess for can easily be done in PHP, custom WP rewrite rules and redirects, or Nginx rules

[mcyzyk]

Thanks, Tom!

My issue is that all our WP hosts here are under Apache, so switching to Nginx is a non-starter.

I could move configs such as, e.g., "php_value max_execution_time 300" out of .htaccess to elsewhere (php.ini/wp-config.php) but would have to be cognizant that what's running in VVV is not really an exact duplicate of what's running on our host. Not ideal, especially when trying to troubleshoot something on our host, but running it locally, is what I'm trying to use VVV for in the first place.

Thinking...

Thanks again,

Mark

[tomjn]

My issue is that all our WP hosts here are under Apache, so switching to Nginx is a non-starter.

I didn't suggest that!

I could move configs such as, e.g., "php_value max_execution_time 300" out of .htaccess to elsewhere (php.ini/wp-config.php) but would have to be cognizant that what's running in VVV is not really an exact duplicate of what's running on our host.

You could do it via wp-config.php then it would work on all servers Apache or Nginx, WordPress itself does this with the memory limit constants it provides so it's not without precedent. I don't see why max_execution_time would make HTAccess a requirement though, is that all that you're needing HTAccess for?

Unless something specific to the HTAccess is causing your issue though, Apache/Nginx should not cause issues at the application layer. If that is the case then either the fix is in the HTAccess file, or something has gone terribly wrong.

[tomjn]

BTW If you share your HTAccess I might be able to help wrangle alternatives that work universally, it'll help anybody with similar issues searching as well as shape what Documentation for HTAccess users might look like

[mcyzyk]

Thanks.

Here are the settings from .htaccess I need to move to wp-config.php:

php_value upload_max_filesize 50M php_value post_max_size 50M php_value max_execution_time 300 php_value max_input_time 300

It's looking like there are different syntaxes for these, .htaccess versus wp-config.php.

Searching...

[tomjn]

It's pretty much this in a HTAccess file:

php_value ini_setting_name ini_setting_value

becomes this in generic PHP:

ini_set( 'ini_setting_name', 'ini_setting_value' );

if setting the ini file fails it will return false if you want to check for success. This is how WordPress is doing it behind the scenes. Of course if WordPress provides a constant for it, that would be the best option.

With this you can eliminate those lines from your HTAccess and the configuration should work on any server that runs PHP.

In the grand scheme of things these 4 values are unlikely to matter if you're debugging something unless you're getting errors from Apache itself about the specific things they cater to, but there's always the chance the hosting server is configured ot ignore the php_value directive

[tomjn]

Using your example this:

php_value upload_max_filesize 50M
php_value post_max_size 50M
php_value max_execution_time 300
php_value max_input_time 300

Becomes this:

ini_set( 'upload_max_filesize', '50M' );
ini_set( 'post_max_size', '50M' );
ini_set( 'max_execution_time', 300 );
ini_set( 'max_input_time', 300 );

There's a constant for max memory limits but you're not setting that here so I can't find any WP constants for those 4 items

[tomjn]

As for other common things in HTAccess,

• the multisite and pretty permalink rules already have equivalents in the Nginx config VVV uses
• for redirects that aren't http->https you can do these on the init hook in PHP with wp_safe_redirect if it's for a URL on the same site, or with wp_redirect, wrapped in an if conditional, and an exit; statement immediatley after the redirect. There are plugins to automate this but you might prefer to roll your own
• A lot of HTAccess rules that rewrite ugly URLs into pretty ones to hide things are actually better done with WP rewrite rules, and if done that way might have better SEO and sitemap support
• for more obscure mappings, you can write a custom Nginx config by copying the default in the provision subfolder and adding your own additions to the new file, I forget the name the new file needs to be but it's in the docs site. This is your escape hatch if you need to do truly bizarre things or have something bespoke, usually useful for enterprise hosting

[mcyzyk]

Thanks to you, my goal of using VVV (the Swiss Army Knife of Wordpress development) to troubleshoot my issues on my Development WP instance (running the apparently problematic PHP 8.1) has worked. In PHP 8.0 in VVV all my Troubles go away.

Could not have gotten this to work without your helpful guidance.