I'm working locally on a WordPress site for a client. The client keeps their install of wordpress in the server root, but because I have more than one client, I like to install everything in a client folder, like localhost/client. Normally it's a simple matter to add a rewrite rule to .htaccess, setting the rewrite base to be /client/. But today it's not working at all. Even if I put nonsense in the rewrite rule, the site works (which it should not, if the rewrite rules are in effect). The images references are still looking for root at localhost/, instead of localhost/client/, which means they are broken.
I looked into WordPress's documentation and found it has something called WP_rewrite, and there is a place to set parameters for it in wp-includes/rewrite.php). I set the root parameter to client/ but that doesn't seem to have any effect either.
One last thing: there is an .htaccess file in localhost/client/, and another one in localhost/client/wp/. I have them both set to RewriteBase = /client/, but I've tried just about every other sensible combination--no change.
So my question is: does WordPress do something else that would make the rewrite rules I set in .htaccess not work?
I'd recommend a small change to your local environment for a more flexible solution. Use virtual hosts. If you're running WAMP/MAMP, this tool is readily available to you. It allows you run a directory within your localhost as its own site, which you can access using a local-only URL of your choosing. I have my sites set up as sitename.local, for instance, so they all live in their own happy little ecosystem. Highly recommended.
Yes it does, you have to make some steps that will change entries in db before you move it to subfolder.
Here are detailed info:
http://codex.wordpress.org/Moving_WordPress#Moving_WordPress_Within_Your_Site
What you need to do:
copy everything as it is setup on your clients server i.e. in root folder
do the steps in above url, important are 4. & 5.; step 10. actually just go to permalink settings and click on "Save" button (or "Update" I do not remember how it says)
Now you can work :)
Are you modifying only theme or what?
Related
Okay so I have a Magento 2.4.5 project where I am facing some issues like images not loading up because they are being looked up inside pub/media/wysiwyg instead of media/wysiwyg. I have some wysiwyg images inside pub/media/wysiwyg/<some_image_directory>, however on the live site the directories and files are showing up as media/wysiwyg. How can I make sure that a separate pub/media/wysiwyg directory is created in the live site apart from the media directory that is already there such that the image loads up properly? We are using nginx which is opening up at 'pub' directory as the root where the media directory resides. Any help is appreciated.
I tried checking for the piece of code where the image is coming from in an attempt to see if the path can be changed programmatically by removing the 'pub/' part from the pub/media/wysiwyg/ for the live site. However, that is not something that can be done as that will change things project-wide, which might break other things. Hence that is not being done.
First, you need to make sure that you are running the site from the root folder i.e. public_html on the server.
Steps to reproduce:
1: Run the command to load content:
bin/magento setup:static-content:deploy -f
2: Next command: chmod -R 777 pub/*
3: Set the secure base media URL and unsecure media URL from Magento database which you recently created and find the table core_config_data and change the path value as:
web/secure/base_media_url => https://example.com/pub/media/
web/unsecure/base_media_url => https://example.com/pub/media/
Or from Magento Admin
Stores -> Settings: Configuration -> General -> Base Url's -> Base URL for User Media Files
and to
Stores -> Settings: Configuration -> General -> Base Url's (Secure) -> Base URL for User Media Files
Flush Cache
4: Might be missing .htaccess in your /pub/media/ folder.
5: Check your .htaccess file, if there's bad code.
Thanks
Okay so I figured out the issue.
I was running the website from the pub directory as I should however there was a third party plugin which had some hard-coded src set by the owner for images set as /pub/media/wysiwyg in the adminHtml since they were using an older version of Magento which used to place images inside /pub/media/wysiwyg instead.
So I just changed it to /media/wysiwyg over there and everything works as expected.
Tbh the whole issue was quite hacky as the owner seems to have put a script inside the third party module's description section in the adminHtml and is using hard-coded links such as this.
Thank you all for the comments. :)
I have to move an existing Drupal site from one server to another. I've done so by doing a mysql database export/import and copying over the files to the new server. On the new system, the root page comes up fine but if I try to go to any deeper directory levels I get a 404 Not Found Error.
so drupal.newserver.com -> works fine
but drupal.newserver.com/user -> gives me a 404 and happens,same for all subdirectories
Is there something that I'm missing that is part of a drupal export? Could it be related to the structure of the /sites directory which is under the webserver's docroot?- which has a folder named after the old server (ie drupal.oldserver.com but not drupal.newserver.com? Also, I noticed that there are _htaccess files and .hta files but not .htaccess files in the site files that I've copied over.
Sorry if I'm asking a bleedingly obvious question - I'm very new to Drupal. Thank you!
Check whether the clean url is enabled in your web server. To check try this:
drupal.newserver.com/?q=user.
Just to let anyone who might come across via a google search - I was able to get this to work . It turns out that while mod_rewrite was enabled, what I had to do was to enable the AllowOverride directive for the web directory in httpd.conf to be set to ‘All’. If it’s not set to this, the server won’t respect the .htaccess rules you put into the drupal directory. It’s been a while since I’ve worked with apache config files so it took a while to finally piece it together. The main breakthrough came when I realized that if I turned off clean-urls then the links worked but looked ugly and then was able to research clean_url.
I'm trying to set up wordpress so that relative paths work on both my localhost development and my live site.
I was hoping it was just a matter of changing the "site" URL and "home" URL to http://localhost/ and www.example.com, and then links would be relative. However this is not the case, and I think .htaccess complicates the issue.
Eg, if I want to access a file in www.example.com/wp-content/mydirectory I can do this:
$url = '/wp-content/mydirectory/myfile.php'
but on my local site I have to do this:
$url= '/www.example.com/wp-content/mydirectory/myfile.php'
I have a solution by conditionally echoing a var at the start of the path, but it's not always possible to use PHP to accomplish this, for example, in a post or page where the link is in the content.
Does anyone have an elegant solution?
Go to the database and look inside the config table. There's a value for home (and possibly another value called URL, the table is not too big, so give it a quick scan), change that to your local environment for testing and when you're ready, you can change the record in the database and upload to your remote server.
I would like to move a test Drupal installation from
/opt/lampp/htdocs/corporate/internet
to
/corporate/internet
What corresponding changes changes do I have to make in .htacess, settings.php and/or other settings?
That depends on that how your sites/ directory is set up. If you just have a default directory within, they you really should be good to go.
Mostly, you don't have to make changes. This is because Drupal installations tend to be set up to use relative paths that will be valid no matter where in the system it is. You may want to do a quick search of any custom code for the string /opt/lampp/htdocs to see if someone didn't do something relatively, but any other contrib code should work fine.
As Jubal mentions, sites set up in the sites directory may need renaming if you're going to be using a different URL to access the site - if you're moving from devel.site.com to www.site.com, and you have a sites/devel.site.com directory, then you're probably going to want to copy that directory to sites/www.site.com. On the other hand, if you're using sites/default for your site, or if you're not changing the url at all, then this isn't a problem.
Do note that the .htaccess in the root directory of Drupal is very important for Drupal to work, and that doing a simple cp -R of the directory will not copy the .htaccess, so make sure you copy that. (.htaccess files in sub-directories, like sites/default/files, will be fine, it's just this one in the root.)
And finally, check your file permissions after you move the files. You'll especially want to make sure that the file permissions for the files and tmp directories are correct so that people can properly upload files. (This may not be important - but it's something to check nonetheless.)
I'm using multisite to host my client sites.
During development stage, I use subdomain to host the staging site, e.g. client1.mydomain.com.
And here's how it look under the SITES folder:
/sites/client1.mydomain.com
When the site is completed and ready to go live, I created another folder for the actual domain, e.g. client1.com.
Hence:
/sites/client1.com
Next, I created symlinks under client1.com for FILES and SETTINGS.PHP that points to the subdomain
i.e.
/sites/client1.com/settings.php --> /sites/client1.mydomain.com/settings.php
/sites/client1.com/files --> /sites/client1.mydomain.com/files
Finally, to prevent Google from indexing both the subdomain and actual domain, I created the rule in .htaccess to rewrite client1.mydomain.com to client1.com, therefore, should anyone try to access the subdomain, he will be redirected to the actual domain.
This above arrangement works perfectly fine. But I somehow feel there is a better way to achieve the above in much simplified manner. Please feel free to share your views and all advice is much appreciated.
Since it seems you want to reuse the files/ directory and settings.php from your development domain, I'd suggest using the default/ directory + symlinks to achieve your goals.
ie, during development
sites/default/settings.php
sites/default/files/
sites/client1.domain.com -> sites/default (symbolic link)
once you're ready to switch over to their domain:
sites/client1.com -> sites/default
You can then remove client1.domain.com from your virtual host (or continue with your rewrite, etc...).
It will accomplish the same as your method, but you get the added "protection" of all requests going to default in case you add an additional domain at a later date as an alias (for example).
If you're simply sharing core and module files between the sites, you can use a different symlink layout.
In my setup I have all of the shared files in a common, non-web-accessible directory:
/var/www/drupal
/var/www/drupal/sites/all/modules
then for each deployment, common files and folders are symlinked to those files.
/var/www/client1/public_html/index.php -> /var/www/drupal/index.php
/var/www/client1/public_html/includes -> /var/www/drupal/includes
...
/var/www/client1/public_html/sites/all -> /var/www/drupal/sites/all
Then you can place the site's settings.php and any modules or themes for only that site in the default sites directory
/var/www/client1/public_html/sites/default
This layout also offers you the flexibility to override any common files as necessary, such as .htaccess.
To move from staging to production, you will just have to modify your virtual-host configuration from the staging to production domain name.
If you don't like a ton of symlinks, another option is using the Aliased Multi-Site Support patch:
http://drupal.org/node/231298#comment-1420180
This will allow you to specify in configuration that any requests for client1.domain.com should actually use /sites/client1.com/ instead of /sites/client1.domain.com/.
Then when you move to production, you can just remove the configuration setting (though it doesn't hurt anything if you don't).
This feature is part of Drupal 7, but as a new feature won't be added to Drupal 6. More good news is that you won't even need to use it in D7 just for file paths, since instead of storing the full path to files in the database, they use a schema such as public:// or private:// which Drupal then maps to the correct file system path, allowing multiple storage types/locations with much better portability.