Yet since the Bitnami WordPress stack is shipped with WordPress configured to be at LOCALHOST/wordpress/, and the live website will typically be at root, Bitnami provides an easy way to reconfigure WordPress to be at root.īut the reason why that is important is only URL writing.
#Bitnami mean stack apache httpd.conf how to#
There is still the same hassle: I should figure out a lean method to set up a WordPress site offline prior to migrating it online following Shubhang’s instructions on How to Install WordPress Locally on your PC (and practice making your website). Sorry for duplicate posting in the meantime.Īnd sorry for asking this question here, after all. Reason: moved to Locahost Installs since this is a localhost install This topic was modified 2 years, 8 months ago by James Huff. Now my questions are: Why does WordPress keep responding and displaying at root when it isn’t configured to do so, and what takes it to move WordPress’ base URL to a directory **after it had been at root?** But / does, additionally to /blog.īitnami offered great support and helped sorting things out, while advising to reach out for WordPress to ask for help ( ), as this is an application-specific issue to be addressed here. The only thing that changed is that /wordpress doesn’t work anymore. Instead, the request is now redirected to /blog/, and the blog’s homepage is served.Īnd the most bizarre is that out of 4 manually added links in the page footer, that all have relative URLs at / to 4 pages of the blog, 2 are opening their page at /, and 2 at /blog/, despite I cleared the browser’s cache multiple times and even restarted Chrome (beside restarting Apache again after manually changing from /wordpress to /blog). And when I request the /, Apache is even prevented from serving the Bitnami start page.
At the beginning, Apache was able to serve independently a handful pages at /svg/. The problem I’m encountering is that in either case, once the blog engine had been at root, it keeps supporting URLs at root, no matter what URL it is currently set to. It is pretty straightforward and works as documented. Then I’ve checked how it works out when setting /blog instead of /wordpress, as suggested in. That wrong behavior may result from WordPress-internal records. So I was able to repurpose apache2/htdocs so that a handful pages at /svg/ could be served by Apache independently.īut that is now definitely compromised because WordPress has now “learned” two URLs to use interchangeably: /wordpress and /. When I checked it, WordPress had already been reconfigured starting from the /wordpress directory in an instance of the local WordPress stack from Bitnami.īitnami had made the wise design decision to ship self-contained application stacks with a /appname base URL, not at the localhost port’s root. WordPress, when it is configured to be at root, processes all requests at this port and sends its 404 when it’s not in the blog.īut that keeps happening even after these three files have been edited: apps/wordpress/conf/nf, apps/wordpress/htdocs/wp-config.php, and apps/wordpress/conf/nf. I’m having an issue with configuring WordPress’ base URL.
0 kommentar(er)
