I developed a website in wordpress and used several plugins. One of the plugin was http://wordpress.org/extend/plugins/background-manager/
Every thing was working fine on my machine. But as i get uploaded it to client server. the whole site stuck due to lower version of PHP. This plugin requires PHP 5.3 and on server we have PHP 5.2. Since its a shared server, we can't upgrade its PHP.
Then i look into the code of this plugin it was using PHP 5.3 feature namespaces. Is there any way to downgrade this plugin that it will work with PHP 5.2?
This is a really tricky problem, and of course, it's really, really bad practice to use old code for plugins as they may have fixed security vulnerabilities or other serious problems. It would be better for you to move the site to a server with more up to date PHP.
Having given that important warning, you can, however, browse to the tags directory in the plugin repository and extract the files you want for the previous version. Plugin history is public and always maintained.
For instance, for the plugin you mentioned, you can visit the SVN part of the plugin repository at:
http://plugins.svn.wordpress.org/background-manager/
You'll find the previous versions there under the "tags" folder, named after their versions.
Related
I am looking to integrate version control into my Wordpress development workflow. I have experience with Git in rails application development, so that seemed like a good option. However, I haven't found any holistic information that pertains to my needs and is in my knowledge level.
I would like to be able to accomplish the following:
develop site locally(I would only be touching the theme files for the most part, so I would want to look to the production environment for the rest of the files to avoid redundancy)
have Wordpress look for theme information in my repository (most likely will be on Bitbucket, but am open to server hosting solutions)
I hope that I am describing this clear enough for someone to have insight. If not I am glad to go into more depth of my goals.
You can refer to "WordPress + Composer + GIT"
It uses (in addition of Git) Composer (a dependencies managing tool for PHP), and WordPress Packagist (a repositories site that automatically packages the plugins and themes available in WordPress site in the format required for working with composer)
That way, you keep a declarative approach where you declare ion a composer.json what you need: this is easier to version in a Git repo.
Probably a silly question, but I cannot find any good advice on the internet so far, so hopefully you guys have some good advice. I would like to use GIT for version control and use it to deploy changes to my websites to the server(s). It's easy when I use NodeJS, but a bit more complicated when using a CMS system, to my opinion.
When I use NodeJS
When I use NodeJS it's quite easy to have a node_modules folder which contains all the external libraries which I will install on deployment. The rest(my own files) will be saved on Github and deployed to my server if changed. Obviously I will not store the node_modules folder on my Github account or send it to my server (node modules will be installed on the server, on deployment). So it's pretty easy to keep those two (third-party an my own files) seperated.
When I use Wordpress, Magento or something similar
Now it gets complicated. Mostly because CMS systems like Wordpress have a folder structure like wp_content/themes/theme_name/, so your own theme files are more or less entangled with the core structure, instead of separated like NodeJS. And it doesn't seem right to commit all my core files to my Github account as well or send all those core files to my server on every deploy (I would prefer to install them using composer or something, serverside), because I'll never touch the core files, obviously.
So is there any advice? Is there a better whey to handle this? Maybe change a configuration file with the path to my theme folder or something?
The best way to do this is to move your wp-content folder outside of your standard installation. I tend to have a folder called "wp" with the basic WordPress installation in it and a folder called "wp-content" at the same level for my content files. You can then tell WordPress that your content folder is elsewhere with the following:
define('WP_CONTENT_DIR', dirname(__FILE__) . '/content');
That goes into wp-content.php which you can also take out of the main WordPress install (and thus add to git) and place at the same level as your folders.
To make things even better consider looking at composer https://getcomposer.org/ and using that to bring in WordPress core and plugins https://wpackagist.org/ is your friend here. This guide got me started on using composer with WordPress and its a good start https://roots.io/using-composer-with-wordpress/ you can pull in your theme from git as well via composer which is great for when you deploy etc... Capistrano for example can run composer on a server :)
For instance, the yet-to-be-released Twenty Twelve theme is available on GitHub, but it's a Forge build.
And in order to retrieve the actual theme with the normal directory structure, I'd have to install Ruby, RubyGems, Forge and some configuration to go with it.
I am no developer and I just want to use the theme. Is there a way to manually pull out the theme files from the build?
This is what I am thinking:
All the required template, JS and CSS files are in the build directory.
Add html5.js to the javascripts directory inside build directory. Then rename javascripts directory to js (<= compared its directory structure to that on WordPress.com SVN)
Now rename build directory to twentytwelve—the theme is ready.
Is that all, or am I missing the whole point?
PS: I am sure that some of you'd suggest me to download the theme directly from the WP.com SVN repo., but the reason why I don't want to is that on GitHub I can easily track the changes to the theme.
If you really want to just get the latest, ready-to-go version of the theme, use SVN. They push updates over when it's in a stable form, so you don't need to worry so much about whether or not there's broken functions in the version you're grabbing - or any number of weird issues when using an alpha build of the theme.
While that will kind of work, you should really either:
Use the GitHub repository the way it was meant to (clone it, and use Forge to build the theme).
Wait for the theme to actually be released.
While you might be able to extract the theme as-is from the /build directory, there's no real way for you "track the changes to the theme" since the changes will be made in the /source directory. There's no guarantee the committers will build the theme before pushing (which is how the /build directory is currently kept in sync.
Update
If you've been following active development, Twenty Twelve was just rolled into WordPress trunk for the upcoming (late 2012) release of version 3.5:
Changeset 21261
Timestamp: 07/12/12 04:20:46 (14 hours ago)
Author: nacin
Message: The Twenty Twelve for WordPress.
props drewstrojny, lancewillett.
also props corvannoorloos, jeffsebring, kobenland, iandstewart, mfields,
mtdesign, op12no2, philiparthurmoore, sixhours, mamaduka.
So rather than playing around with extracting the theme via GitHub, just use Subversion to check out WordPress trunk and look at the /wp-content/themes/twentytwelve directory.
There's nothing 'easy' about the way you're suggesting going about it. Certainly not easier than installing SVN, pointing it to the repo, and tracking changes there (you know, when they're actually done). It's still version controlled, still easy to see the diff, and still the latest version. Also, note that in github, the theme files do point to /javascripts, so if you're renaming the directory you'll have to manually catch it in the files themselves as well.
If you really want to just get the latest, ready-to-go version of the theme, use SVN. They push updates over when it's in a stable form, so you don't need to worry so much about whether or not there's broken functions in the version you're grabbing - or any number of weird issues when using an alpha build of the theme.
It seems like lots of people are using xdv successfully so this must be something I'm not getting about xdv. I am running 4.0.3 on my local server (Mac). I have a xdv theme running in Plone (diazo.example.com) and I am trying to modify the styles. I can see my changes on apache and DW but they do not appear in Plone. I have debug mode on. I tried deactivating and activating the theme and emptying the cache. No luck, the site does not update. I thought it was 'easy' to make changes on-the-fly with xdv but this has me stumped. I didn't register the stylesheets in CSS registry. Is that a critical step or optional?
On another note, is it worth it to switch to diazo and plone.app.theming? What are the major benefits of doing so?
Thanks!
Elaine
I absolutely recommend that you switch to diazo and plone.app.theming. This is most easily done by starting with Plone 4.1.x instead of Plone 4.0.x. Get a copy at http://plone.org/products/plone/releases/4.1
Then, using buildout, install plone.app.theming. You may have a few issues with lxml, but since you've already done xdv I figure you've conquered that already.
I've been reading about drupal install profiles, and I'm wondering if there's much of a difference between using a packaged install profile vs. installing core + manually installing the modules listed in the install profiles?
I'd like to do the latter (manually installing each) to control the versions of each module installed, which I can't control with a packaged install profile that may not have been maintained.
But should I or will I be opening the door to something I'm not aware of? Shouldn't the 2 be identical, just one automated and other is manual?
What kiamlaluno said, plus the fact that installation profiles may perform custom configuration of settings on install, might construct custom views/content-types/etc (especially by means of features.module, which you can see heavy use of in OpenAtrium), and might provide other custom code in distro-specific module.
The short answer is, no you can't just replicate an install profile by downloading a clean drupal with all those modules -- best bet is to use the install profile. If you're worried about module versions, just make sure you're using a profile that's actively maintained.
The difference is that an installation profile includes the right version of all the modules it needs.
This means that differently from manually installing each module, you don't need to verify the correct version of the module X that effectively works together the module Y; there are few cases where one module doesn't work well when version A of another module is installed, and you need to install version B of the same module, if you don't want problems.
An installation profile can have a custom installation page that allows you to change some parameters of your site; it also allows the installation profile author to define a patch that needs to be applied a module, in order to fix a bug of the module, or to make it work better with another module.
If you need to set a site to work for a particular purpose, installation profiles are useful for you as they allow you to set the site correctly without to know all the details about how a Drupal site needs to be set.
I believe you can specify the versions of the modules you want to install see