I've having an annoying issue with Wordpress.
First I have to say that I'm not very familiar with Wordpress, I’m using it because I agree to take the management of the website of my sport club.
Now let’s me explain the issue. The previous manager of the website found a plugin that he think will be nice for the website.
But now that I’m managing, I want to make some change to this plugin (which is under GNU GPLv3 License so I have the right to do it).
So I install wamp on my computer, then wordpress and then I add the plugin to it in the purpose to test my changes.
I was thinking that when editing the files under “…\wp-content\plugins...” it will take effect instantly but it’s not.
I try to restart wamp after making some changes but it does not solve my issue.
A bit later I found that in wordpress there is a plugin modification interface and when going in it I found that the changes that I made on the files where not taken. Is there a cache of the files or something?
So my question is the following: Is there a way to edit the files in the folders (I’m using Visual Studio Code) and that the changes are applied instantly to the “running” plugin in my local instance?
I hope I was able to be clear enough so you guys can understand me
Thanks in advance
I am helping a friend build a simple Wordpress website, their current website is with a hosting and domain service called https://www.icuk.net/.
The website is very poorly built on this platform. I told them I'd make a website for free on WordPress as I have some experience with drag and drop WordPress website builders.
My question is, if I use the platform's one-click WordPress installation, does it automatically delete the website that was previously using the domain and hosting? If so, could anyone explain in layman's terms how I would go about backing it up, as it's always better to be safe than sorry.
I would be hesitant to do this, personally. I believe you can use the one click service to uninstall, at which point you can install WP again. A better option, however, if WP is already installed, would be to just change the theme, deactivate and delete any unwanted plugins, and then delete (or change to draft if you may want any of the content for your new development) any unwanted posts or pages. A current version of WP is a current version of WP, thus there is no reason to reinstall. Once you change the theme, remove the posts and pages, and remove the plugins, you are essentially back to a new install. Maybe do that instead?
Thanks for taking the time to read this.
I have a WordPress plugin hosted on GitHub - lets call this plugin 'LK-FORM', and it's running on 3 different live websites. 'LK-FORM' is exactly the same for each website.
These 3 different websites are also running locally using Ampps.
My question is; How do I get 'LK-FORM' to be in 3 local websites but still update the master branch on GitHub when one of them is changed so that all 3 live sites stay up to date.
I've cloned 'LK-FORM' into one local plugin folder, but when I go to clone again, the repo isn't there anymore since it's already listed on the GitHub GUI. Any help would be greatly appreciated.
Sounds like a use case for git submodules, although a Google search will turn up many articles against their use. Submodules have a lot of gotchas, but you can make good use of aliases or tools like gitslave.
Edit: You could also just clone to one directory and symlink the others, adding them to .gitignore to prevent redundancy.
Openshift's default app generator sets Wordpress creation of sites to be a non-scalable version of their gears. I'd like to know if there is a way to set a scalable instance and install wordpress on it.
thanks!
I am working on this today actually and got a scalable wordpress site up and running on OpenShift. (www.runcloudrun.com)
I disabled the symlinks in the action_hooks and manually added my theme and plugins to the php/wp-content/themes and plugins directory. I also used a S3 plugin to store all of my media files on amazon s3 so my images and media would scale once OpenShift adds addiontal gears.
I am writing a blog post on how to do all of this and it should be posted later this week.
Edit to add the blog post: http://www.runcloudrun.com/?p=22
--
gs
You can checkout this AppFog solution. And if you visit his Github you'd find an OpenShift wrapper as well. These two might give you all the sparks it needs to think out a scalable solution on Openshift.
Just use the git source URL and create a new app with PHP. Once the app is created, add MySQL to it.
Once you've created the app, the important next step is to check in your modules directly to the Git repo.
By default, we wanted folks to be able to download plugins directly from Wordpress, but when you scale, those files aren't copied over. Also, the filesystem for each gear in a scaled app isn't shared, so modules uploaded after you scale aren't magically copied to all gears. Given that limitation, we decided to mark the QuickStart not scalable, so as to prevent unfamiliar users from getting into trouble.
If you're familiar with Wordpress just check those modules in directly to your source, and everything will scale.
I run my blog using Wordpress and all too recently became a big believer in SCM. I really want to put my site into subversion (that's what I'm using right now, maybe git will come later) but I can't think of the correct way to do it yet. Basically, my repository is set up currently with an 'implementation' directory and a 'resources' directory, with implementation holding what will eventually be published to the live site. I want to be able to preview my site locally without having to upload to the server for obvious reasons. However, to do this I found that I needed to actually install Wordpress locally (not just copy the remote site down to my local box). This was told to me over at Wordpress.org.
This brings up the problem of being able to use SCM with the install because I need to upgrade my local site every now and then but this generates inconsistencies with subversion because it can’t track what’s going on because an external system is messing with it’s repository structure. That just won’t work.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
Anyway, I’m sure other people have tackled this and the solution is probably applicable to many apps similar to Wordpress (Drupal, phpBB, phpMyAdmin, etc.). So, how do you do it?
It's actually not that hard to do, but I'll break it down into a few suggestions here. What you're describing is more or less a "vendor drop" directory. This is basically where you maintain the code in SVN, but replace the contents with the newer stuff as it comes out.
What you should start with is an empty directory. Set up an SVN repository, and then do an SVN checkout into the empty directory (it will still be empty, except it will get a hidden .svn directory added). Next, install wordpress here normally, and then add its files to svn. You can probably just "svn add *" but be careful, and remove anything you don't want versioned (uploads/temp/cache directories, if applicable). You can also use the svn:ignore property to tell it to ignore certain directories or file types, if you'd like. Run "svn stat" to show you what is going to be checked in, etc, and once all is good, commit it (svn commit) and start working from there. Now you have a base installation of wordpress in SVN.
As you work and make changes, commit them.
When it comes time to upgrade, simply replace wordpress over top of what you have. Make sure when you replace directories, you replace the contents, and not the whole directory itself. You don't want to lose the hidden .svn folder in every folder because that is what will mess subversion up. Do an svn stat and/or svn diff to figure out what's changed, if anything, and mostly what's newly-added. At this point, you can commit again.
To deploy on your production site, you can do an svn export, or do a regular checkout into the web directory. If you do a checkout, be sure to only update when you are ready to deploy.
This is the method I'm testing. It takes some time to setup but you should then (in theory) have a future-proof install:
Installing WordPress The Right Way
Also look at svn:externals for pulling in plugin updates:
Use svn:externals to install WordPress plugins
I think the upgrade part can even be a little easier than that; I do this with the most current version of both 2.5 and 2.6, as well as bleeding-edge trunk revision of WP.
Since Wordpress offers all of their stuff as subversion repositories, getting the current rev of a stable tag is as easy as making the blog directory and then
# svn co http://svn.automattic.com/wordpress/tags/2.6.2/ (replace the current rev here for the first check out).
When an upgrade is available, simply navigate to your blog directory and run
#svn sw http://svn.automattic.com/wordpress/tags/2.6.3/ (or whatever wordpress rev you're updating to)
Then releasing to your production site is just an export, as gregmac mentions
However, I don't think this answers your actual question, which I interpret as "How do I keep my custom stuff in SCM while being able to upgrade Wordpress". Your instainct about what directories to tack is pretty much on target (your own personal blog's stuff - themes, pplugins - will be in wp-content, so you should only need to put that into subversion) but I'm not proficient enough with subversion to tell you how to place the directory into your own repository while still being able to rely on Wordpress's repo for upgrades. My "SCM" for those files on my site is an off-server copy of the wp-content directory.
Maybe from that standpoint gregmac's answer works better for you.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
That's exactly how I version control my blog. I've found that it works great. Generally, if you're editing WordPress' files, you're doing it wrong and will be in for misery when it's time to upgrade.
To simplify this, I use TortoiseSVN. I navigated to my /wp-content/themes/ directory in Windows Explorer, right clicked on my custom theme's directory, and chose import from the context menu. After importing all of the existing files, I performed a checkout on that directory and everything was set.