Here's my situation. I'm trying to use Chef to install a drupal site (purely automated, no human input). So far I have been able to use drush to install drupal7.
Once I have all the drupal files in my document root folder, it seems that I need to physically go to the browser and complete the install script on the website. If I don't, the drush site-install created the drupal db, but it has no tables.
Surely there must be a way to more or less follow the install script on the website through the drush command line? Any help would be greatly appreciated, and let me know if there is anything I can clarify. The container with drupal is on Ubuntu 14.04, I am using Drush 7.* and want to install Drupal 7.x.
Without knowing exactly what arguments you're passing to drush site-install, it's hard to figure out where the problem is. This answer assumes that you're running MySQL
Assuming you're running a command that looks like so:
drush si standard --db-url=mysql://dbusername:dbpassword#localhost:port/dbname
--db-su=name --db-su-pw=password --site-name="Your New Site"
If tables aren't being created, I'd first make sure that the mysql user you're running as has create table permissions for that database. An easy way to root out whether it's a permission issue would be to use root username and password details.
If that doesn't resolve the issue, enable your database's logging to see if create table commands are being issued by drush.
Hope this helps
Related
I'm new into Git and I'm working with Wordpress themes.
I was always using FTP client to push every small change into my remote server... I mean sometimes it was just one line of code to check the change of CSS. It was easy and nice but there will be always problem with reverting changes and since I'm learning Git, I want to change it.
I've found two ways to do it:
git-ftp
i've tried to connect my local respository with GitHub and my intention was to automatic pull changes into my remote server from GitHub (it's not working yet, i need to configure it better)
BUT, do I have to commit every single small change? Because I cant just save file and check changes with Browsersync on second monitor, I will have to commit so many times. Also which way will be better for me - maybe there are another, better ways?
I really want to improve my performance, but it looks like that's not easy or I'm doing something wrong? I know about existence things like WP-CLI, webpack, gulp but often I'm creating small websites and probably I will spend more time on configurating those things than create theme. Also I thought about working on localhost, but I really think that I'm complicating things and my job.
Really sorry if it's wrong section, but I'm new on stackoverflow - hey! I will be really thankful if you can help me, because I think that i need knowledge of someone experienced.
I'm not sur to be helpful but I'll try :
First, even for a small project, I always prefer to install a local environment for testing. It avoid risks on your remote server !
You can take a look here : https://make.wordpress.org/core/handbook/tutorials/installing-a-local-server/
Then, if you have an SSH access to your server, may be you can try to configure it to push directly from your local environment to your remote server. Here is a simple tutorial : https://gist.github.com/noelboss/3fe13927025b89757f8fb12e9066f2fa
It depends on what remote system or vps you are using.
It could be from GCP, AWS, DIGITAL OCEAN, or WP itself.
It looks like that you are using the wordpress hosting your website.
If so, you might use wp cli to login the server.
①As for the frequent testing and updating, it is a good idea to copy the remote project to your localhost. Run your web app using wampserver. And create a new repository in the github and connect it with your local folder.
Then you could use git to version control your codes, do pull and push, stash or whatever.
And after testing, you could upload the specific files or folder to the remote server via ftp or sftp periodically.
②Another way is to install the git bash or git software in your server side.
It depends on the OS you are using. If it is a win or linux.
$ add-apt-repository ppa:git-core/ppa
$ apt update; apt install git
and create new user, add it into the sudo group
create a repository in your server side and link it to the github remote repository.
I am not sure whether the second way would work.
I recommend you try the first method.
Hope this could help. Happy coding.
I ran across the VCCW project and despite my unfamiliarity with Vagrant and Chef, decided to give a try. I followed their instructions and obtained the VCCW project itself by installing the GitHub Windows program and cloning the VCCW GitHub master repository. I should also mention that I have very little experience with Git.
Anyway, now I have VCCW Wordpress running on my machine, but I've no clue what to do from here. I wanted to set up a better and more formal Wordpress development environment so I could write my plugin and modify a theme, but I don't know where I should do that. I know where the actual Wordpress installation resides on my file system, so I suppose it would be easy to work from there, but I don't know how (if at all) that interplays with the Vagrant workflow - ie, when it comes time to use Vagrant to deploy my site, will my changes to the "www" folder (which was created by vagrant up) be captured? Somehow I doubt this. Just looking for any help as to how all these fancy new tools work with each other and what a humble PHP developer like myself should do to get started.
Edit: One more question: which IDE, if any, can I use in conjunction with this arrangement? Create a new project from existing sources, and let it pollute my deployment folder with project files?
From the Vagrantfile, it looks like you should look in ./www/wordpress after provisioning.
VCCW includes deployment tool WordMove.
You can deploy WordPress into your server from vccw if you set Movefile.
Movefile will be created automatically after provisioning, so you should add your server configuration in Movefile.
http://vccw.cc/#h2-10
https://github.com/welaika/wordmove
This is a noobe question. I am trying to clone a Drupal website on WAMP to test some local development. The current website is maintained on Aegir. With the owners' knowledge but for reasons that I don't know, I have not been able to get information directly from whomever is managing the website.
I have been able to scp the platform [profiles, modules, files etc]. My current puzzle is how to obtain a copy of the database so that I can import it into WAMP.
One of the files that I have copied is called database.sql and is a healthy size (35MB). I have looked around the web and no one outright says this is a readable form of the MySQL database.
My attempts to import it into a database of the same name and username failed with a suggestion the size was too large. (password unknown - have several versions looking at the documentation and cannot tell which one is which).
Working from the MySQL console: mysql -u usernamenewdatabase -p newdatabasename < C:/path/database.sql
Also failed.
Can anyone cut through this muddle for me? Am I even on the right track?
Thanks
Jo
Thanks for jogging me along. WAMP just replies with a suggestion that the file is too big.
I have solved it in the meantime.
Yes - database.sql in Aegir is a straightforward .sql file
To get it into WAMP in particular, the solution is to edit this line of config.inc.php file in the wamp/apps/phpAdmin folder
$cfg['UploadDir'] = 'upload';
by inserting upload beween the ''
And then add a subdirectory to phpAdmin called upload.
Put the big file in the upload directory and import it into a clean database from the phpAdmin screen.
Ridiculously easy when we know how.
Thanks Clive - I appreciate the support.
I have a couple of working Drupal installations on OpenShift. I prefer OpenShift for testing and development.
However of late when I try to install a new instance of Drupal the 'php' folder is missing and as a result editing of any files is a real nightmare. I decided to create a 'php' folder and build my drupal from there.
The challenge however has been that with every update that I push my settings.php file is deleted and I have to fix it via SSH just to get working. This is a real bother and am looking for a better alternative to working with Drupal in peace on OpenShift.
The QuickStart has changed to automatically deploy a Drupal instance in your data dir and symlink the changes. This means at create time you get the latest Drupal and you can configure and deploy Drupal live. If you prefer the old model, just copy the php folder off the gear and check it in to your source repo. The hooks (which you can also change) won't deploy Drupal if you have a php folder - meaning your base Drupal still works.
We made this change so that folks creating a new instance got something running immediately that was up to date with security patches (and so you install modules to the server directly). Settings.php lives in your data directory and is symlinked in vs being copied.
You can continue to use the old Drupal-example repo as well.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-