I recently installed Exceptionless on a server for testing purposes. Now how do I go about completely removing it from said server? I have uninstalled and deleted all the directories for both ElasticSearch and Exceptionless. When I reinstall it again, it says my email already exists. I basically need to completely remove the tool from my system, so that I can try different configurations. Any help would be greatly appreciated.
I work on the Exceptionless Project. You just need to remove the website and Elasticsearch instance that you configured (if you only set it up for Exceptionless). If you delete the Elasticsearch folder you should be completely free. If you are using redis, you may want to flush the redis db to start over. Were you able to get it working?
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 had a perfectly working instance of a WP-CLI wordpress plugin to upload files to S3 using the AmazonS3FullAccess policy. I migrated servers, and the copy started failing. "Failed to copy or write".
I even included the Full Administrator access to the IAM policy just to see what's going on when there are no restrictions, and the copy is still failing. Any idea what might be wrong?
Things I have tried: ensure time (via NTPD synchronization) on the new server is correct. Cross check the environment: php version, etc. The application files are exactly the same. I also used the host files method to check the previous server and it is working well.
Solved the problem by creating new access keys. For some reason, it seems that migrating a server will make the old access keys stop working? Ah, well.
P.S. I also downgraded the policies right back, to only what the application needs.
I have a WordPress website up and running with many plugins installed on it and a huge database, I need to use chef-solo in order to create an environment in which can install the same website with all its plugins and and also importing its database.
I need it to be like, using chef to install the same website on a different server, exactly the same
Now here are my questions:
I know we can use chef to install WordPress but can we set it in a
way that we don't need to configure the the WordPress and everything
is already set once its running?
What to do with the plugins? can we install them using the chef or
now that should be done manually?
How about importing the database, that can be done with chef-solo
as well?
The whole website is on git, can I somehow import the whole
thing?
is there any other issue I may possibly face? if I want do that?
There is a wordpress cookbook openly available for chef.
When you mean configure, I take it you mean setup data in the database. Assuming that you've separated the database instance from the server instance, and you're attempting to scale up the number of servers then you should be able to skip data setup. You should be configuring the new server instance (node) to point to the same database via Chef.
I stumbled into this question looking for the answer to this question. From what I can tell the start may be here.
Kind of hand-wavy, but this should enable you to do some wordpress stuff via the command line with Chef, rather than the point and click it prefers.
As per #1, you should not need to import the database. If the database goes down, you'll want to focus on that as a separate but connected recipe, since then you'll want to be taking snapshots and uploading them somewhere like S3 via a cron job. I believe there are plugins that can enable this.
You'll have to be a little more clear by "import". If it's in a code base you may be able to short-cut your cookbook path by pulling down the git repo onto the host. You may want to look at git-archive.
Other issues that I'm looking at are images. We're migrating from a hosted solution to AWS, and it appears that instead of storing the images in the database, word-press pulls them into a local directory. This means that if we scale to > 1 host, we'll have issues with images. Something to think about, there's a wealth of plugins that can probably solve this.
Hope this is helpful,
Ben
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-
Can you help me to understand, how do I do Drupal website deployment and development?
Suppose, I developed 1.0 version of Berty&Frank website. I copied everything to their production server and it is alive and kicking now. Site is already full of contents and is growing.
I am asked to add additional features to the website. I am now experimenting with the way how I can implement them in a dev version. I am creating/deleting content types, fill created nodes with demo data just to see how they look like etc. Now I found the way and I want to upgrade production website to the same structure as my dev version now. How do I do that?
Is the only way to manually make every change I made in dev version?
I would explore the Aegir project for the future management of your website. It allows you to clone a site, then to upgrade the site to a new "platform" which could be the next release of Drupal or another Drupal system (such as OpenAtrium).
More can be found at the aegir wiki.
You can export/import views and contenttypes, but a lot of settings etc is stored in the db. This gives two options
Either to use something like backup & migrate to import your settings from dev. This wont work if you have test data though, as you would overwrite the db.
The other options is to repeat what you did on the live site.
A third options could be to take a fresh dump of the live site, do all the settings in that db in dev environment and overwrite the live db with that. You could loose some comments etc, but shouldn't be a big deal.
I use Subversion, and just do an update on my production server when I am satisfied with the code on my development server (actually, I have a staging server that is a duplicate of the production machine, so I update that before the production; I can see any bugs that might pop up).
For database changes, I haven't found anything better than just keeping track of my changes (usually adding/modifying CCK fields) and performing the same changes to the production database. I also download my production database regularly, so that dev and staging have almost the same content. That helps to minimize the confusion.
read http://www.drupal.org/upgrade/