Cloning GS sites to new domains

[grassfrog]

I notice that, while it's easy enough to copy over an entire GS site into a new httpdocs directory, chmod to 777 and go into the admin to change the base URL under Settings, I still get an error message when I update anything in the CMS Settings page.

Error: Unable to continue: Unable to write config file. CHMOD 777 the folders /data, /backups and their sub-folders and retry

The funny thing is, I have already CHMOD'd everything to 777 (-R) and while I get the error, it doesn't appear to be valid as the changes I put in DO write to the site.

I can easily enough just ingore the error, but it will freak out my end users when they go to update their sites. So, my question is, how do I suppress this error message?

[ccagle8]

is there a gsconfig.php file in your site's root folder?

[grassfrog]

Yes, I copied the entire site from a working instance including the .htaccess file, and then CHOWN'd and CHMOD'd as required. Installing via FTP takes way too long and is prone to errors but SSH works like a charm, except for this little hiccup. Any ideas?

[marrco]

Yes, I copied the entire site from a working instance including the .htaccess file, and then CHOWN'd and CHMOD'd as required. Installing via FTP takes way too long and is prone to errors but SSH works like a charm, except for this little hiccup. Any ideas?

I never user FTP to setup GS. I prefer to wget/unzip/mv or svn export. I don't chmod, just chown to www-data:www-data -R the root and never had a problem. Tested today with actual 3.1 on debian squeeze

[Mark Nielsen]

It's saying it can't write the config file? That's the gsconfig.php?

Just a wild stab in the dark, but check the permissions on the web root directory as well? Do an 'ls -a' and show us the results?

[shawn_a]

Your having and issue writing the user settings or website settings file probably.
These are in data/users and data/other
Did you run health check ?

[Zegnåt]

Is it just me or does every CHMOD error tell you it couldn’t ‘write configuration file’? Very annoying. This problem has nothing to do with gsconfig.php:

I still get an error message when I update anything in the CMS Settings page.

Is it only with settings or also when you update a page? The CHMOD error is thrown per the result of XMLsave():

Code:

function XMLsave($xml, $file) {
    $success = $xml->asXML($file) === TRUE;

    if (defined('GSCHMOD')) {
        return $success && chmod($file, GSCHMOD);
    } else {
        return $success && chmod($file, 0755);
    }
}

As you are saying the file is correctly saved the first part of its check must be true, leaving chmod() to be the problem. Can you check if the GetSimple is allowed the run chmod() on the server?

[grassfrog]

Your having and issue writing the user settings or website settings file probably.
These are in data/users and data/other
Did you run health check ?

No issue with health check. Honestly can't see any reason why copying a website instance from one directory to another would cause this type of issue, especially since it's only on the Settings tab and nowhere else.

On an unrelated note, how dangerous is it from a security standpoint to chmod all these directories to 777? It seems like this is a security breach waiting to happen...

[Zegnåt]

On an unrelated note, how dangerous is it from a security standpoint to CHMOD all these directories to 777? It seems like this is a security breach waiting to happen…

Even with it being 777, whoever wants to change the data will need to have access to a user on the server. Most hackers are likely to get either root access or FTP access, meaning that lower CHMOD will not keep them away from your files anyway.

Note that GetSimple by default uses a CHMOD 755. You could use this too since you have said you have CHOWN’d the files. It will be more safe. The only reason we tell people to use 777 a lot is because they are copying sites (as a whole) from their Windows development environment to a Linux web server over FTP. This breaks a lot of things when it is set to 755 because the owner changes. It is easier to tell users to CMOD to 777 with their favourite FTP client than explain to them how to CHOWN.

[grassfrog]

Thank you - that does clarify things quite a bit. Because I was chmoding to 777 then chmoding back to 755 before release (of course retesting to ensure it didn't mess anything up).

The one thing I've noticed with all of the CMS systems is that, the more information you give people about how to break in the more likely it will be that they do. I've been fairly lucky thus far (with almost 9 years of CMS based hosting for hundreds of websites) but I really do try to be careful about granting access, and I monitor my logs daily.

Any other thoughts on the original error? FTPing a new site instance takes over 1/2 hour (longer if the FTP times out and I have to go through and check every folder for completeness) so I really need to get this nailed down as an SSH install in order to make this a production level product.

[Carlos]

FTPing a new site instance takes over 1/2 hour (longer if the FTP times out and I have to go through and check every folder for completeness)

Yeah, uploading an unzipped GS can be a pain depending on the server. I usually do it via cpanel.

I suggest you use some temporary php script to uncompress your GS zip file directly on your web server. Googling for "php unzip server" should give some examples...

[grassfrog]

That is a good suggestion, however one you have a number of themes and plugins working on an instance, along with content and base metatgs, it's still more efficient to clone the site and then change the the elements to make it unique to the new instance. Otherwise, you're looking at FTPing the main engine, installing it, then adding the individual plugins (testing each time to make sure that they don't break anything). You can still clone over the themes directory from a main repository, but then there is still the issue of getting the original instance's content copied over without causing anything to break or throw an error.

Maybe I'm asking too much, but copying over an entire instance then changing the file permissions & ownership still seems to be a reasonable and logical method for creating additional GS sites. I just need to figure out how to keep it from throwing an error message under Settings.

Yeah, uploading an unzipped GS can be a pain depending on the server. I usually do it via cpanel.

I suggest you use some temporary php script to uncompress your GS zip file directly on your web server. Googling for "php unzip server" should give some examples...

[vasitellapahki]

I'm having the same kind of problem with one GS installation (or migration to be correct).

Settings page:

Code:

Error: Unable to continue: Unable to write the configuration file. CHMOD 755 or 777 the /data, /backups folders & sub-folders and retry.

Every change to settings is saved though.

Same problem with i18n Gallery.

Code:

The gallery could not be saved.

Changes are saved though.

Ownership problem?

I have done health check, everything OK, checked /data, /backups folders & subs chmod is 777.


EDIT
I got things sorted out, it was a problem with website hosting. They corrected it and now everything's working ok.

[jorre]

I got things sorted out, it was a problem with website hosting. They corrected it and now everything's working ok.

Can you be more specific about what fixed this issue. I'm set all permissions to 777 on the files and folders causing the issue, but I still get the error. The settings are saved though...

[jeremiah.holder]

I'm moving a GetSimple site from one cPanel account to another (from test to production). The health check is fine.

I followed the practice of installing a new instance of GetSimple setting the domain url to the new one. I moved the /data, /plugins/ and /theme folders to the newly installed site.

Everything works as expected in the admin area. The default page (Home, index.php) appears when navigating to the site. All is good UNTIL the loading of any other page content. I get the (unfortunately) too familiar message: "We are sorry, but the page you are looking for does not exist."

I copied the .htaccess file in the root of my test site to the production site.
All file permissions are set to 755 for content and 644 for config files.

Code:

AddDefaultCharset UTF-8
Options -Indexes
DirectoryIndex index.php

# blocks direct access to the XML files - they hold all the data!
<Files ~ "\.xml$">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>
<Files sitemap.xml>
        Order allow,deny
    Allow from all
    Satisfy All
</Files>

RewriteEngine on

# Usually it RewriteBase is just '/', but
# replace it with your subdirectory path
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule /?([A-Za-z0-9_-]+);(\d+)/?$ index.php?id=$1&page=$2 [QSA,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ([A-Za-z0-9-]+).php index.php?id=$1 [QSA,L]

# Enable GZIP
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</ifmodule>

# Expires Headers - 2678400s = 31 days
<ifmodule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 7200 seconds"
  ExpiresByType image/gif "access plus 2678400 seconds"
  ExpiresByType image/jpeg "access plus 2678400 seconds"
  ExpiresByType image/png "access plus 2678400 seconds"
  ExpiresByType text/css "access plus 518400 seconds"
  ExpiresByType text/javascript "access plus 2678400 seconds"
  ExpiresByType application/x-javascript "access plus 2678400 seconds"
</ifmodule>

# Cache Headers
<ifmodule mod_headers.c>
  # Cache specified files for 31 days
  <filesmatch "\.(ico|flv|jpg|jpeg|png|gif|css|swf)$">
  Header set Cache-Control "max-age=2678400, public"
  </filesmatch>
  # Cache HTML files for a couple hours
  <filesmatch "\.(html|htm)$">
  Header set Cache-Control "max-age=7200, private, must-revalidate"
  </filesmatch>
  # Cache PDFs for a day
  <filesmatch "\.(pdf)$">
  Header set Cache-Control "max-age=86400, public"
  </filesmatch>
  # Cache Javascripts for 31 days
  <filesmatch "\.(js)$">
  Header set Cache-Control "max-age=2678400, private"
  </filesmatch>
</ifmodule>

My settings page uses a fancy URL structure of "%slug%.php"

Any guidance as to what I am missing would be appreciated.

It seems I always get hung up on these .htaccess files.

[dblewett]

I notice that, while it's easy enough to copy over an entire GS site into a new httpdocs directory, chmod to 777 and go into the admin to change the base URL under Settings, I still get an error message when I update anything in the CMS Settings page.

Error: Unable to continue: Unable to write config file. CHMOD 777 the folders /data, /backups and their sub-folders and retry

The funny thing is, I have already CHMOD'd everything to 777 (-R) and while I get the error, it doesn't appear to be valid as the changes I put in DO write to the site.

I can easily enough just ingore the error, but it will freak out my end users when they go to update their sites. So, my question is, how do I suppress this error message?

I've cloned a site a few times, and have figured out a pretty simple method that works perfectly.
1) I unzip the file locally and upload the complete set via ftp.
2) Run the install script and set up the site and any default settings.
3) Delete theme and plugins directories.
3) Upload via ftp the theme and plugin directories from the previous site.
4) Enable the plugins.

That's it.

[shawn_a]

Your htaccess does not contain rewrite rules for fancy urls.

[jeremiah.holder]

Your htaccess does not contain rewrite rules for fancy urls.

My rewrite rules are the same I've used in each of the sites I've done so far:

Code:

RewriteEngine on

# Usually it RewriteBase is just '/', but
# replace it with your subdirectory path
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule /?([A-Za-z0-9_-]+);(\d+)/?$ index.php?id=$1&page=$2 [QSA,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ([A-Za-z0-9-]+).php index.php?id=$1 [QSA,L]

These are contained in the .htaccess attached above. I've come up with this .htaccess after reviewing and compiling all the various threads for optimization. I believe it is correct, but maybe I've missed something?

Like I said in the original reply. All plugins, functions, photos, etc. from the data folder appear to work properly. It comes down to the page content itself. It is my experience this is almost always the .htaccess being misconfigured. I'm just not seeing it.

[shawn_a]

Can you get to your slugs the normal way?
Index.php?id=

[jeremiah.holder]

Can you get to your slugs the normal way?
Index.php?id=

Yes I can.

[shawn_a]

Sorry my iPad was not showing code scroll bars.

It's gotta be your rewrite rule, check server logs see if it tells you what it's actually trying to load.

Or start off simple with the default htaccess and permalink

[shawn_a]

Oh and you have duplicated rules and some which will never be executed.

[hoemaco]

Yes, I copied the entire site from a working instance including the .htaccess file, and then CHOWN'd and CHMOD'd as required.  Installing via FTP takes way too long and is prone to errors but SSH works like a charm, except for this little hiccup. Any ideas?

I never user FTP to setup GS. I prefer to wget/unzip/mv or svn export. I don't chmod, just chown to www-data:www-data -R the root and never had a problem. Tested today with actual 3.1 on debian squeeze

It's seven years later now and still in the http://get-simple.info/wiki/installation:migrating site I don't see it written
that one should do a chown.

While the admin php will ask you to chmod to 755, it's irrelevant and doesn't do anything.
Either the files are owned by www-data (or whatever user the webserver (eg Apache) is running under) and then it will have write access to the files; or not, in which case only 777 would be useful. But the latter is a security leak. Some here wrote that it's not -  well I did get my site hacked in a day. In a university server. (A php code (in base64!) was included into one of the php files that I accidentally left on 777).  And when you upload from local PC to server, the file owner will never be www-data.

So the only solution to me seems to chown all files to www-data and make sure that write permission is only set for owner.

It would be nice to have in the migration wiki site, it would have saved me some time.. (I even had to find a new hosting solution as the original one didn't allow me to chown).   I can edit the wiki but would consult with you folks first.