I want to do developments on my client's website but by making a clone of it. So, main website url is: http://website.com and the clone i am trying to create is: http://test.website.com.
So far i've done the following:
copied entire root directory into public_html/test dir (with folders config,field,FirePHPCore,fontyourface,includes,js,misc,modules,scripts,sites,styles and themes)
created a subdomain in cPanel for test.website.com
checked the file settings.php (inside sites/default folder) for $base_url but found it commented, so left it as it is unchanged.
copied db via phpMyAdmin and updated the new db details in settings.php (inside sites/default folder).
inside the table variable, two rows with the name securepages_basepath and securepages_basepath_ssl. Changed their values from http://website.com to http://test.website.com (using the variable_get and variable_set functions).
Now i can access http://test.website.com but when i click on login (from header) it takes me to http://website.com/user and if manually type http://test.website.com/user and login then it takes me to http://website.com/users/admin then i have to manually type in correct address http://test.website.com/users/admin.
And when i logout, it again takes me back to http://website.com.
So i want to know how can i completely make it to work on http://test.website.com?
Are there more variables to change?
And how i can make 100% sure that the test site is only using test and not the live site. I am afraid of messing up live website.
Please advice, thanks!
I fixed it by disabling the secure pages from inside the mysql database. It was inside variable table and securepages_enable field. It was in blob so i had to download the blob first and opened it in notepad and changed the value inside it from 1 to 0 and then uploaded it back by updating the securepages_enable field.
I had to do this because after logging in from my test url, the urls were redirecting back to the live website, so whatever change i was making, it was all affecting the live site.
Hope this helps to someone with similar case. Thanks!
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 an instance of Silverstripe that we have copied off a webserver that we host. We are trying to get it running locally so we can modify it but when I run it locally all assets point to the live site. Also I cannot access the login, or Admin pages of the CMS.
When I try access any local pages it states "Server Error" in the page content
Is there a place in the code where I can change the paths to assets to local, and also access the Admin area?
Assuming you're running a local copy of the database, and don't have any exotic changes to the way File is handled SilverStripe should be resolving file paths using the BASE_PATH and BASE_URL constants.
For logging in you'll want to add to the bottom of mysite/_config.php locally something like:
define('SS_ENVIRONMENT_TYPE', 'dev');
SSViewer::set_source_file_comments(true);
ini_set('display_errors', 0);
error_reporting(E_ALL);
Security::setDefaultAdmin('admin', 'admin');
// Email::setAdminEmail('admin#example.org');
define('SS_LOG_FILE',dirname(__FILE__).'/'.basename(dirname(dirname(__FILE__))).'.log');
ini_set('error_log', SS_LOG_FILE);
Director::set_environment_type('dev');
This should give you enough debug information to solve most issues.
I would use something like https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ (which also works for Silverstripe), to do a search and replace for all occurences of the old domain.
This would mainly work for images paths that are inside of content fields of course. Otherwise, SS should automatically convert the paths, as the accepted answer suggests.
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 am trying to create an identical wordpress website - on the same server. I need to create this as a testing environment but every time I try to duplicate the site it breaks. Is there an easy way to create a testing environment, of the live site, on the same server while keeping all of the same widgets, plugins and content?
I am an experienced web developer but a novice when it comes to Word Press.
I appreciate the help.
In my experience the following usually works:
Setup your prod site
Copy all files to the test site
Modify the wp-config settings as needed, and create the test db schema
Export all the data from the prod site control panel and import into the test site
The problem is that while you have all the files identically, your database contains all the configuration information for the live site. You'll need to copy the database from live to your development/testing server. You can run an export on the SQL and import the data into a new database. Then modify the wordpress/wp-config.php file in your development site to connect to the new copied database.
Additionally, you'll want to go through the new copied database, table: wp_options and change the site URL to match the development site/server instead of the live server.
Some default fields you'll want to change are:
option_name: home
option_name: siteurl
As well as fields installed by plugins that contain your site URL and path.
Create a directory for the testing.
Backup the original database, and
create another one (you may use the
same db user/pass if you like).
Execute the SQL file from the backup (at the test database)
Edit the wp-config.php.
(Test Database) Update the URL at the (your prefix)_options table. It's the very first value with the option name: siteurl
Done.
I have recently moved a drupal site. (both servers run on a debian based LAMP stack) Everything works great here, including the uploading of images via a CCK filefield. Original url:
dev.example.com/foo
Deploying it to a test folder on the production server to a test folder for an environmental shakedown cruise lead it here:
www.example.com/foo
Everything works here too, including image uploads. After adjusting sites/default/settings.php, then making it readonly again, I renamed the folder to its production name:
www.example.com/bar
Everything works fine here except for image uploading. I've adjusted the webroot variable within settings.php .
Things I have tried so far:
Gave php system user write permissions to sites/default/files (images are set to go in sites/default/files/images but imagecache just puts them in sites/default/files)
Enabled file php file uploading for www.example.com/bar/sites/default/files
Are there any other configuration settings I should be looking out for here? I'm running low on relevant solutions.
Edit: I had quite the typo there, I adjusted sites/default/settings.php, not sites/default.settings.php .
Your question is slightly confusingly framed. default.settings.php has no impact on Drupal -- its merely a template. The file that contains the actual database connection information and other configuration is settings.php.
You may also want to look at your .htaccess file in your root Drupal folder and try changing the RewriteBase directive to the folder you are accessing your site on. Usually you should not have to change the $base_url directive in the settings.php file that you may/may not have done. Reverse that change for now if you have (you may need to play around with that later though).
imagecache will always upload the image derivatives in sites/default/files but imagefield will upload the original image in the folder you specify (within sites/default/files). You will get a setting for the imagefield under Manage Fields->[Name of Image field]->Configure under Path Settings.
Please google to understand the difference between imagecache and imagefield. Make sure your sites/default/files (and subfolders) are writable by the apache user (usually www-data).
In such situations, its usually a good idea to pick up a book on apache (if you haven't already) and try to understand how it works. It will be time consuming but will help you out in the future when you encounter configuration issues like this.
This worked for me. When having issues uploading images to a cck field, I gave write permissions to directory:
sites/default/files/field/image