Wording Within the Official ocPortal Support Docs

Just wondering if I am reading this wrong or this is a minor typo?

Within the: ocPortal Tutorial: Moving servers (including copying 

themes manually)


Does this read correctly:

If you are moving URLs, then you need to use the base configuration editor (the config_editor.php script) to change your base URL setting, and then to clear your caches using either the upgrader.php script or the Cleanup Tools in the Admin Zone.

If you are moving URLs but not servers, there is no need to perform any of the steps below. Simply moving the files directly on the server will suffice

 


Should?? It not read "moving servers but not URL's"?

No, but it is unclear. I will change it to:

If you are moving URLs but not servers, there is no need to perform any of the steps below. Simply move the files to the new domain webroot directly, and update the base URL as described above.

First, "My Bad" on that botched/oversizeed text and screwed up link that I have no clue why/where it takes you. I believe it was around 3:30am and I was falling asleep. My forehead kept slamming into my key board. Sorry for you having to hunt it down.

Also thank you for correcting the doc Chris and it may just be a slight issue Midwestern America slop-jaw meets British, Old English slang, but I am doing a rather large transfer of an existing ocPortal. As I will explain further down, this is the first time I have actually needed to transfer ocPortal and it is an install which has been only (v6) upgraded and running now for well over a year or so. So far, besides trying to squeeze one big round .sql dump into a square hole uploading using PHPMySql. This is another beast I will take care of, but even having all php.ini settings maxed or -1, everything above the max_upload allowed size, yet for some reason I am still getting large-file size errors and not because of file name or timing out.Either I will ftp, command line or figure out how a pre-v2.07 of PHPMyAdmin snuck itself into my new server configuration. Besides that I am primed to finish this transfer and just want to be-sure that I am on the sam page since I have questions still and love perfection when it comes to slipping in any size website in a new server. 

---

Now, 

Proper link: http://ocportal.com/docs/tut_moving.htm
 

---

Objective: Only "new" within the following is the bare-metal of a new server and a new static IP. Transfer an existing ocPortal install from Point A to Point B with no files being changed, URL/domain staying the same, paths, user names, passwords and even OS installs.

To be ultra clear here, when "URL" is used within the "Moving Servers" documentaion does it mean when someone purchases or obtains a new domain name and applies this new domain name (re-domaining a website) to an existing install of ocPortal started using another domain?. Same/everything, but simply renaming their website from www.petsarecool.com to www.ihatepets.com. Just want to be clear that URL does not pertain to something further and into the some aspect of configuring a uniform resource locator.


The Scenario: 
Let's say I person was moving on up from shared to VPS, or shared to dedicated, or VPS to dedicated, or just sprung for the best IBM or Dell offers and they goal in moving ocPortal to a/another server is purely just this, moving to a new or another server. The Directories, files, SQL dump, themes and URL/Domain will remain the same as they had when installed at point A, but in another hosting environment/server when the dust settles and ocPortal lands at B.

In the above situation and using identical paths, users names, passwords, etc.., all a person would/should have to do before leaving the old server/host is zip up or FTP download ocPortals entire directory and files, sneak into PHPMyAdmin and pass a SQl-dump from MySQL.

At this point they would SFTP & SSH into their new server and once the new server is configured and web ready, they would manually upload the old/original (no new files are used at any point) ocPortals directories and files into the new server's web root (/var/www/mywebsite.com/public_html or similar). Then right after (or before) they would take the old/original .sql dump from the old install at point A and upload it into the new server's database at point B. At this point, again nothing new or changed from point A, they would just have to clear cache and check permissions correct?

---

My Question:


Now, as I was reading the guide and came upon this point below: 

If you are moving URLs, then you need to use the base configuration editor (the config_editor.php script) to change your base URL setting, and then to clear your caches using either the upgrader.php script or the Cleanup Tools in the Admin Zone.

---

If you are moving URLs but not servers, there is no need to perform any of the steps below. Simply moving the files directly on the server will suffice.

​​​​​​​​​​​​


For some reason I expected the second paragraph in the above to go into and pretty much say what I had typed out above what I quoted from the documentation based on how I was reading into the entire doc. If you look closely to how it is worded in the second paragraph, I know East Coast/West Coast/Overseas, but it starts out by saying:

Quote: "If you are moving URLs but not servers"

Then in the next sentence says:

Quote: "Simply moving the files directly on the server will suffice"

With the above sentence being right under a title/heading of "Moving Servers", I am taking the use of the word "moving" as in moving them to a new server, with this simply sufficing and nothing else being needed which I believe would be untrue?

Now reading the first sentence of the second paragraph over again, it blatantly and clearly states that it does no pertain to moving servers, but only changing URL/Domains. Thus not moving any directories or files to a new server.  

Now, I can certainly "dig it" if this: "Simply moving the files directly on the server will suffice" merely means that when someone changes their website's URL/Domain of an existing ocPortal website that transferring directories and files "within" their existing server to do so will suffice, but want to be very sure that this actually means this.

The reason I am questioning this heavily and have drawn out in detail what I am after is that I am indeed transferring a rather large existing ocPortal install/website from one server to a new server. Besides new the bare-metal and huge increase in RAM, every aspect including URL/Domain, paths, webserver, username, permission, password, OS, database, etc, etc, etc… will be identical when the transfer of ocPortal is performed. Like anyone ever in the history of web roots, I would like to minimize my chances of any lengthy downtime and have ocPortal slide right into a new home, up and running and 100% even before the Domains are pointed.

So, I assume if all goes as planned, I should only have to run some of the upgrader.php and make sure to clear cache, check permissions and change (or chase down) where I may have used an actual instance of the old IP within ocPortal. 

Amazingly I have never had the need to shift an existing install of ocPortal before.

So, wanting to be doubly sure given how I still am read this section, along with the sake of sanity and not having to throw in the towel to go live 3 days later because I boofed a simply process or an area of configuration, I typed out the above so I can obtain to the mojo to just push forward. I have done many entire and large website, shred to shared, dedicated to shared and shared to dedicated, RackSpace Cloud server to Cloud server, Cloud sites to Cloud Sites, Dell, IBM, Windows, Unix and with scripts such as Ticki-Wicki, UbbThreads (large forums) and others so I know the details can wig anyone out prior and thus why I am asking in detail.   

one big round .sql dump into a square hole uploading using PHPMySql

BigDump: Staggered MySQL Dump Importer

To be ultra clear here, when "URL" is used within the "Moving Servers" documentaion does it mean when someone purchases or obtains a new domain name and applies this new domain name (re-domaining a website) to an existing install of ocPortal started using another domain?. Same/everything, but simply renaming their website from www.petsarecool.com to www.ihatepets.com. Just want to be clear that URL does not pertain to something further and into the some aspect of configuring a uniform resource locator.

It's no more or less than what it says. The tricky thing with writing documentation for ocPortal is so many people are doing so many things which makes it hard to be clear.
Changing the URL could be because you've bought a new domain, or it could be you're setting up a new test site by copying an existing site, or it could be you've decided you do or do not want "www" in your URL. There could be various scenarios.

In the above situation and using identical paths, users names, passwords, etc.., all a person would/should have to do before leaving the old server/host is zip up or FTP download ocPortals entire directory and files, sneak into PHPMyAdmin and pass a SQl-dump from MySQL.

At this point they would SFTP & SSH into their new server and once the new server is configured and web ready, they would manually upload the old/original (no new files are used at any point) ocPortals directories and files into the new server's web root (/var/www/mywebsite.com/public_html or similar). Then right after (or before) they would take the old/original .sql dump from the old install at point A and upload it into the new server's database at point B. At this point, again nothing new or changed from point A, they would just have to clear cache and check permissions correct?

Sounds right. It's just a matter of transferring data correctly and clearing out caches that may have been too server-specific.

Quote: "If you are moving URLs but not servers"

Then in the next sentence says:

Quote: "Simply moving the files directly on the server will suffice"

With the above sentence being right under a title/heading of "Moving Servers", I am taking the use of the word "moving" as in moving them to a new server, with this simply sufficing and nothing else being needed which I believe would be untrue?

The second sentence relates to the first. I'll change the full stop between them to a colon. The paragraph is just trying to give a special case for people who actually don't need to follow the steps in the main article. Yes it is true those people perhaps should not be reading a tutorial called "moving servers", but we picked the tutorial name to reflect the most common scenario even though it covers related ones.

So, I assume if all goes as planned, I should only have to run some of the upgrader.php and make sure to clear cache, check permissions and change (or chase down) where I may have used an actual instance of the old IP within ocPortal.

Yes, it is actually quite a simple process. The tutorial probably is not even needed. ocPortal tries to be very portable so issues rarely come up.

Added this…

If you don't have shell access to import a database you'll probably end up trying to use whatever the web hosting control panel provides, which is usually phpMyAdmin. However you will struggle to import large databases with this. You may therefore find this tool useful: BigDump: Staggered MySQL Dump Importer.

Thank you Chris. once again you been very helpful and I had figure it was this easy, but --ocP being as sophisticated as she is--, wanted to be sure. 


Thanks for the big sql dump info also. Moving forward with 100% confidence and will report back on how it all rolls together. Should be a piece of pizza and work out just like downtown.

LOL---at me----> "PHPMySQL"

I meant to post ---PHPMyAdmin---

I own the entire boat, slip and dock with this server so shell access is 100% accessible. I had gotten a little lazy they other day and installed PHPMyAdmin. Actually I had it in included in one of my custom Ubuntu build commands line up and I am still wondering why an older version of PHPMyAdmin install because I believe 'post' v2.7 a file of the size of .sql should not need any adjustments to the default apache php.ini

Any-Whooo Thank again Chris and hopefully this thread covered some good Google keyword search love content and helps anyone down the road.   

Just wanted to update this. I ended up doing 2 transfers of ocPortal over to their own servers, one being the year old heavy install with cache stemming from around that period of time yet and one being a month a month old and has only seen v8.0+ RCX in its life time.

What caused myself issues was indeed just this, myself.  Brain farting on certain minor things which turn out to be big hassals like remaining logged in as root after creating my FTP user and then staying logged in while I transferred and installed web files. Perms were all over the place.


Then my .tar backup file (at backup which was not created via ocPortal but with a control panel) on the New v8.0-RCX install did not bring the .htaccess files along with it which needed (still adding some) to be added manually per file integrity scan.  Did not notice they were not in place until updating to the latest RC and by then I had done hours of configuring and adding to the website.

The only thing I can say, actually two things, about ocPortal is

1) When perms are messed up on a large scale, no matter how I approached the "./fixperms", it did not seem to help much but I did noticed maybe I could have modified it after the fact to go deeper for me?

2) The newer the install (fresh) the closer the guide provided helps. I did try transferring the first right after creating my last post using the year plus old install (started as a v6/v7 and had since been upgraded to v8) and following the transfer server guide to a "T". Gather a battle plan and approached it once again about a week later and pretty much only modified the info.php file and she was up. Then after the site was up I proceeded to clear cache and correct perms (again the ./fixperms just did not seem to go deep enough). I do have some modifications with the old install but they are done within the "custom" files. Not sure if they had anything to do with ./fixperms or some of the perms being different, then again I believe I found out after the old site transfer that I was logged in as root which is a NO-NO when you want ownership given to www-data. 

I do have a slight issue which I will create another thread about, after I check and see if given cache some time to build back up did not fix it for me.

Captain Kirk said

1) When perms are messed up on a large scale, no matter how I approached the "./fixperms", it did not seem to help much but I did noticed maybe I could have modified it after the fact to go deeper for me?

I've also been having problems with fixperms, but mine were after unpacking a cpanel backup into a vm. I had to do:
to get ocportal to "work", but the file permission checker in the upgrader is still reporting a truckload of permission problems.

fixperms.sh is only need on non-suexec servers, as suexec ones run with the same user that actually owns the files. Possibly the upgrader is picking up on that. fixperms.sh also has been modified in v8 already to do what you had to do temp1024, i.e. ensure non-excessive permissions exist for he sake of suphp/modsecurity.