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