Adding WordPress a second time for a new domain with MAMP
-
Hi, I have 3 domains that I need to create websites for and I want to use WP for all three.
The problem I’m faced with is how to install and set up WP so I can switch between the 3 projects.
My knowledge is limited in this field and right now I’ve got MAMP and WP downloaded and ready to install. Could anyone walk me through what to do different from a typical install for https://www.website1.com and then how to add WP for https://www.website2.com and so on?
I’m a member of https://www.lynda.com and I’ve used the tutorial there for my initial install. It says to stay away from the default directory of htdocs and create a new one under user/sites but I don’t know if that should be done if I’m planning more than one install?
Specifically what I’m wondering is when I go to install the second and third set of files do I put them in respective folders under ‘htdocs’ and edit the wp-config and wp-config files or just crete new wp-config and wp-admin files with respective names i.e. wpone-config, etc?
Much appreciated!
-
You can do this easily for up to three sites using serverpress.com’s desktopserver, or you can also follow these instructions (the not so easy way)
Forgive my tagging on to your thread, jamiedefined, but I’m seeking to solve exactly the same problem so I hope anything I ask or say will also be helpful for you.
The sawmap.com link was very helpful, thanks, and I now have three distinct sites under the local parent directory G:\WebDev\ each of which can consistently be accessed using Firefox 8.0 or MSI 6.0. (To test, I simply used three separate, random but vaguely relevant, web pages and saved them as index.htm in each of the three subdirectories.)
However, what I’m not clear about yet is how I use a single WordPress 3.2 installation (at G:\WebDev\xampp\htdocs\wordpress) and a single copy of MYSQL to manage these three (or more) entirely separate installations. I presume that in the case of the DBMS it would be best to set up a separate database for each local web site and although that’s straightforward enough to do I can’t see anything on the WordPress main dashboard that allows switching sites or switching DBs.
Rooting around I’ve come across the WP Multisite mapping tutorial but that seems to be a case of handling internet-based subdomains rather than what I need. In the plugin directory, under the tag multisite, there’s some possible plugins such as the Networks for WP and the WP Multisite Dashboard widget although again these seem peripheral, if I understand their use correctly.
Essentially all I’m trying to do is the equivalent of opening a word processor and using it to create or edit a range of disparate and entirely unconnected documents.
I imagine I’m just missing something obvious and simple but any pointers or other help would be much appreciated.
MM
Not quite sure I follow the last part about documents. Is it that you wish to work on entirely separate wp sites on your local box or ???
Yes. Exactly that. I (and perhaps from his post also jamiedefined) want to be able to develop entirely discrete and separate local versions of web sites (prior to publishing them online).
The reference to word processing was intended merely as an analogy, and almost any typical program would have done. For instance, and for reasons of obvious efficiency, were I to develop three or four entirely different applications using C++, say, I would use a single copy of the development environment and UI (and DBMS if appropriate) to develop each application in its own space, none of which spaces would interact with any other development space. In like manner I’m seeking to use just the one copy of WordPress (and, indeed, MySQL) to develop and manage several discrete local web sites.
MM
If you want discrete sites, then you need to install a copy of WordPress for each site.
Did you see my reference to ServerPress.com? Full disclosure: I’m the author. Keep in mind that there are two components to making a WordPress site as portable as word “documents”. There are the PHP files that define the look, and the content in a central database. I address this issue with an import/export feature in my product. But essentially, it does what a user would do with phpmyadmin, a handful of plugins and scripts, editing of the apache configuration files as mentioned on my original link https://sawmac.com/xampp/virtualhosts/.
Please note, that this is a “commercial” open source project:
https://serverpress.com/news/getting-started-with-desktopserver/
But I would encourage you to use the FREE version as it will do all that you ask here, short of the ‘portable’ document format which the premium version addresses with a zip file.
I did earlier see the ServerPress.com reference and noted it for later but hadn’t looked. I’ve now checked out your DesktopServer link and I’ll look into that more thoroughly when I can make some time shortly – however, as you say, it looks very appropriate and as the impression I got from reading the page was that it was all well thought out and described I’m sure I’ll make use of it. (Just reread that – I’m absolutely not being patronising, just stating what seemed to me important, believe me!) Thanks for that.
Picking up on esmi’s point – thanks – I’m surprised to learn of that and it seems an odd approach. After all, if one were developing web pages using Komposer or Dreamweaver or whatever then one would use a single program installation however many target sites were being managed. I’m curious as to why WordPress doesn’t natively take a similar approach (style and relevant content files clearly may be specific to individual sites but as those are data that doesn’t vitiate the sound arguments for separating the two and having a single engine to do the overall work). Intriguing!
Perhaps the analogy would be that WordPress is the program, not the document. It contains no data per se. One instance of WordPress on a site manages many pages of that site. The site is an isolated computer. One instance of Word on one computer cannot open up and display a document on another computer’s monitor.
WordPress after all, is simply a content management program.
Actually, that’s really my point, Steve, namely that WordPress is the program, the engine. Sure, Word can’t ordinarily display a document on a remote computer but it has no difficulty preparing a document stored elsewhere than where it’s located whether that’s in a different directory or even on a different LAN or WAN system. So can Dreamweaver, for instance, the display then being handled by an appropriate program such as Firefox used locally and duly calling (conceptually just as does Word where appropriate) on relevant data such as words, images or MUL instructions.
You rightly point out that WordPress manages many pages comprising a given site – why then does it not also have the capability of managing many different sites from one instance running on whatever computer system is being used by the developer? The relatively trivial issue of hierarchy aside that seems to me conceptually no different. I would (if I used it) have only one instance of Dreamweaver but also only one instance of Firefox and thereby be enabled both to develop and, of course, to view many different and discrete web sites and pages.
I accept that that’s just how it is but I’m quite surprised, hence the comments. I guess this really derives from the, to me, vital importance for all sorts of reasons of not mixing up data with utilities to manage that data (programs, apps, plugins, whatever) and unless I’m missing something here WordPress, for all its undoubted capabilities and strengths, seems oddly to be violating that important rule. Thanks, anyway, for the helpful comments.
Because the computer is the site, or the CPU, Word or Excel can only run on the given CPU as does WordPress. WordPress does not run on your computer. When you run WordPress locally, you are merely simulating another computer. ServerPreas does simulate multiple computers aka “virtual hosts” or “virtual servers” but each is isolated. As for each instance of WordPreas is concerned, on instance could be a CPU in the China, another in Egypt. The browser is merely a monitor to each CPU running the WordPress program.
I’d say we’ve pretty much exhausted this – thanks for your comments – but let me make a couple of points on your post.
You write “WordPress does not run on your computer.” Well, actually, it does. I can run WordPress, as I can any other application including browsers, on a system here without internet or other network connectivity.
The whole point of local web development is to trial and test a site in private before going live and public. And no, I’m not “merely simulating another computer” except in the specialised sense of using a test machine to develop and evaluate how something will look and behave on a final deployed site – and that’s absolutely identical in concept to any application development process.
And there I come back to the initial point. If I use, say, C++ for that development I use a single copy to work on half a dozen different apps. If the development is web based then I might use Dreamweaver, say, and in that case I would again use a single copy to work on maybe half a dozen different site developments, straight out of the box. Indeed, if I chose to code the relevant markup languages by hand I’d again use a single copy of an appropriate text processor, just as I would a single copy of a relevant DBMS to manage the half dozen or so databases I might use. And so on.
Only in the case of WordPress, it seems, is the default approach that of requiring multiple copies to be installed, one for each discrete development. AIUI your own product facilitates what I argue is the proper approach so far as separating engines and data is concerned so it’s clearly quite possible (well, obviously it is, irrespective of that evidence!). Given WordPress’s undoubted competence, power and elegance this seems to me a quite bizarre design approach.
You write “WordPress does not run on your computer.” Well, actually, it does. I can run WordPress, as I can any other application including browsers…
Not in the aspect of your analogy such as Dreamweaver. If that were true, why don’t I need to run Dreamweaver to see a Dreamweaver created website? You are proposing that the web server computer turns into a mere harddrive without a CPU to meet your “documents” analogy.
This would require that everyone run WordPress to view your sites and would not be practical. Thin clients and smartphones, and televisions to view the web could not handle the engine that, again is the enterprise “computer” item in this scenario.
Essentially all I’m trying to do is the equivalent of opening a word processor and using it to create or edit a range of disparate and entirely unconnected documents.
If the webserver is no longer the CPU in your scenario, then the “documents” have no logic or processing power within them, what keeps a user from using their copy of wordpress to modify your site? Again, you have to think of the web server computer as the computer in this scenario and your browser as the monitor. WordPress running on a computer in China cannot become patently aware of another WordPress running in Russia. The fact that you can see both web pages side by side on your desktop does not mean that WordPress is running on your Desktop -the web page is being generated by WordPress, along with the logic to keep others from modifying it. For if WordPress was alive on your desktop, how would one submit a contact form, or validate a password once your computer is turned off? The logic needs to run on a trusted CPU. Password validation doesn’t happen on your monitor, it happens on the CPU of the server -the missing key in your analog that prohibits a WordPress site from being treated as mere documents.
- The topic ‘Adding WordPress a second time for a new domain with MAMP’ is closed to new replies.