I installed joomla! 1.5 in a subfolder of my website root. Months later I decided to put the joomla site in the root folder, so I copied everything from the subfolder to the root folder. This worked, but I noticed something strange - the webite data is somehow shared between the two copies. For example, the visitors counter. When I click a few articles in my root joomla copy, I can see that the visitors counter has incremented. When I then enter my subfolder original installation of joomla, I see the counter showing the same value of the root folder copy of joomla. My questions are:
1. How is this happening, can I disable this connection between the two folders?
2. Suppose I choose to continue using the copy of joomla in the root folder without disconnecting the connection with the subfolder installation, am I going to encounter problems, or is it safe to just use the root folder copy?
Thank you very much!
Both copies are using the same database. You'll start running in to issues once you have added any extensions that make changes to the database. There is no need for the old files, just delete them.
Related
I've got an issue where if I upgrade MAMP, it generates a new folder in my Applications folder. So far this has occurred three times now and I'm no closer to finding out why it's happening.
Here's a screenshot of the Finder window showing all MAMP folders. The ones that got created after updating MAMP all have the dates and times they were created.
I've tried deleting the new folders and leaving the original one but that prevents MAMP from opening ("These files are in the trash") but the path for the document root still points to the original folder. Here's a screenshot of that:
Can anyone advise on how best to remove these duplicates and prevent this from happening again? Each duplicated folder adds at least 10GB to my storage and I'm running low! I can't find any reference to this in MAMP's documentation, or even on this site.
Any ideas?
Thanks!
As Peter pointed out that is normal behaviour. The folders containing dates (MAMP_2018-0....) are the backups of the previous installations/versions. The following named folders always contain the latest updated installation files:
MAMP
MAMP Pro
It is advisable NOT to store development sites in the MAMP/htdocs directory. It is advisable to set the Document Root to a separate development directory (not within the MAMP program folder) e.g. DevServer under My Docs.
Before MAMP/MAMP Pro is upgraded record the preference settings. Next upgrade the software and recheck the settings match after the upgrade. Then launch and check your development website(s).
I've experienced this when upgrading in the past. I believe this is normal behaviour.
I have just gotten into the habit of deleting the old ones and haven't had any problems.
I have a Joomla website but I have to admit that it is a mess. I've played with files I shouldn't have been playing with. Therefore I'd like to start over with a fresh installation. But I also don't want to lose my content.
Will it be enough to tell the new installation to use the old database? Or will that break it?
You have 2 option
Start a new installation on the same database and use a different
PREFIX on tables (like newjoo_)
make a bck folder, move existent folders and file in it, copy new
file on the root of your FTP and use the OLD configuration.php file
(so you have new files and old db)
*with the last solution you have a fresh installation but you dont have all old installed extension. you have to reinstall them (and you could have some conflict with existent data)
I'm thinking of hosting WordPress on my Dropbox folder for development work. Has anyone tried this?
I'm wondering if there's a way to keep XAMPP on your local machine but direct the root to the Dropbox folder.
First of all, both WordPress and XAMPP produces a lot of garbage files (logs, PIDs, configs, sessions) etc. that will simply trashout your Dropbox. I'm pretty sure about that, because I tried to version XAMPP on SVN, which is pretty the same as SVN, and got really tired on searching more and more folders that should be ignored (non-versioned) because of containing data and other temp files.
And for answering your question. Sure thing, you can. After installing XAMPP (preferably outside Dropbox), go to "xampp\apache\conf" folder, edit "httpd.conf" file and change the value "DocumentRoot" variable (around line 90) to whatever you need. You may need to use ".." for specifying parent folder many times, if your Dropbox is outside XAMPP folder.
I won't discuss security matters here, as you should know, that such solution is highly risky and on the other side of security topics.
I did a cPanel move of a Joomla 1.5 website and a PHPBB3 forum from one server to another, and when the DNS changes kicked in all I see is a blank page. The administrator panel works without any problems whatsoever. cPanel works. Website and forum (which is separate from the website) are both blank.
I have then manually downloaded and then uploaded all files (didn't move the databases manually), and some files wouldn't upload because of 555 file permissions. I changed the permissions to 777 temporarily to overwrite the file with the manually uploaded one. So all files are now the same as they were on the old server.
Even when I turn the Site Debugging on, the screen is blank.
There is no hidden index.html or default.html file which could be causing the problem.
The entire account was moved with cPanel so it's the same on the old server and the new server. The hosting provider reports no problems. The DNS changes kicked in two days ago.
PHP is working, as this link works: http://oklade.net/findpath.php
In configuration.php, there is nothing specifically pointing to the old site.
var $dbtype = 'WeboMySql';
var $host = 'localhost';
All roads in these cases generally lead to configuration.php Check spelling and punctuation for mistakes. Also, enable one of the default Joomla Templates to be sure that whatever template you're using isn't also using old values.
Problem is solved.
The configuration.php file was to blame, as everyone suggested, but there was no possible way to change it manually and get it right, I had to make the system determine its own configuration.
I installed a fresh version of Joomla in a separate folder, and a fresh version of PHPBB3 in a separate folder.
Then I took the configuration.php and config.php files for those two things and put them in the existing folders of the website which didn't work.
Changed the minor details such as database prefixes (as I couldn't have entered the existing ones while installing), and that's it. Now it works.
So this might be a good workaround for anyone facing the same problem. Install a dummy version of Joomla and use the generated configuration.php file for the old, non-functioning website.
Before starting to debug the server, turn debug-mode on (in the admin CP)
First thing I would try is to delete the cache by running: rm –rf /var/www/html/<your website directory>/var/cache/*
The next thing I would try is to switch to another template - make sure that the template is not the issue.
Also, make sure to check the apache access log - just in case. also, you can check .htaccess for stuff like 301 redirect rules or any other problematic configuration (same applies for httpd.conf and configuration.php)
Good luck!
A while back I was deleting Magento's cache in the var folder. I may be wrong but I think I made a mistake and instead of deleting everything in var/cache deleted everything in var accidentally. Magento seems to be running fine though. Have I got problems that I cant see, can anyone tell me?
Magento 1.6.
It should be fine, the files in there are supposed to be temporary. Just make sure that you recreate the .htaccess file that was in there as it blocks the public from being able to see your log files if you have logging enabled. The .htaccess file just contains these lines:
Order deny,allow
Deny from all
As long as the permissions are properly set on var/ , Magento will recreate the needed subfolders. You may need to create the import and export folders, watch for any other folders that may have been created by third party module installs, they should be recreated if the module programmer did their homework.
I've had situations where I actually had to delete all the folders in var/ so the web server could recreate them with the proper ownership (running as nobody).
In the future in case you're interested in emptying your cache:
Simply delete everything from the /var/cache directory and then reload your website in your browser.
To clear all sessions, you can also delete everything from the /var/session folder within your Magento installation directory.