I wonder what I should be carefull of updating PHP on Windows(with Apache). My current version is 5.2.9-2
My php folder is simply under C:\php
If I simply download and unzip the new version, 5.3, which is a little more significant than going from 5.2.8 to 5.2.9, I'm thinking I need to be carefull not to overwrite some files.
I'm thinking 5.3 will have some changes in the .ini file. My .ini file allready has some modules activated and such, but if I leave the old .ini file, I might have some incompatibilities.
So, what incompatibilities and other risk do I need to look out for? I don't have any experience updating this, and I fear I might loose things and will just end up having to delete and make a clean install and then edit everything again, which is painfull.
Don't do it on a live environment until you've tested.
Php 5.3 contains enough changes/new stuff that i would be wary of either issues with the server config, as you've suggested, but also enough that I'd want to test my app to check it still worked correctly under 5.3 as well.
Related
In my composer.json file I like to list all compatible versions of the (example) package x/y as possible in the require section. Typically that would look like "x/y": "8-10". If I execute composer install, composer of course installs the newest available version of x/y which is 10.x and that is fine, almost always. But sometimes I want to install version 8 of x/y just to check that execution of my application is still possible with version 8.
Another scenario is when a client reports a bug and has version 2.10.4 of some example/dependency whereas the newest would be 2.14.2. The example/dependency is not required by my application directly but transitively by x/y. So I just for a moment want to install my whole dependency tree with version 2.10.4 of example/dependency to debug it with that version of the library.
Of course a temporary modification of the composer.json so that it requires these exact versions would work but that approach seems unnatural, complex, and implies the risk of accidentally committing the modified composer.json to version control and thereby creating a huge mess.
I thought about modifying the composer.lock because accidentally committing a modified version of that wouldn't really cause a problem. But is it okay/recommended to modify the composer.lock file for such purposes?
Ideally I would want a command line argument that fixes some library to some version just for one execution of the composer install command without modifying composer.json.
Since install is meant to read from a lockfile, this option wouldn't make sense for the command.
But for update (and if there is no lockfile, install behaves as update), there is the --prefer-lowest flag (docs).
There is also the option to downgrade a specific package without affecting your composer.json file, by running something like:
composer update --with vendor/package:2.0.1
Mind you, any of these options will modify your lockfile, so after testing you would probably need to git restore composer.lock to go back to the original state.
Commiting a lockfile for a project by mistake should be a biggish issue. Since applications are usually built/deployed by reading the lockfile, a lockfile in an inconsistent state could break things in unexpected places.
But warding of commiting and pushing changes by mistake seems to be excessive, IMO. Developers can make changes to any file, and if they commit those "by mistake", things can break all around.
Expecting a basic "I should look what's changed before staging and commiting" seems a very low bar to me.
help me please:
My case
I have a manually mounted WAMP server using separate packages on drive E:
I did this, so that when I format my computer, I do not have to install it again.
For now everything works very well and little by little I have been making changes in the configurations to make tests.
Today I learned that there is "composer" which allows to manage dependencies for PHP projects.
I downloaded it and installed it (which is very easy).
My question
When formatting my computer and "reactivating" my WAMP, do I need to reinstall composer? Or can I use it as if it were portable?
Composer is just a collection of PHP files, conveniently tied together in one file with the .phar file format (and probably with or without .phar extension). You should be able to either install Composer again, or download that Phar file again if it got lost.
I have a Laravel 4.2 application and it in production environment.
Sometime i have bug fixes or updates for it in the local edition, I want to know how do i move these changes from local to production.
Replacing just the file/class that was changed doesn't work. I tried replacing just the controller file but it doesn't work.
Does Laravel compile the code somewhere that i need to upload to production server, What all do i need to change/upload in production to reflect the changes?
By default, PHP is not a compiled language, so changed and uploaded files will work without any special process. Laravel is just PHP, so it follows the same rules.
However, Laravel uses an autoloader that keeps track of all of your classes. When you add a new class, you need to tell the autoloader that it exists by running:
composer dump-autoload
This will scan the available classes and update the autoloader list.
If the problem persists after you run composer dump-autoload, or if you did not add any new classes, there are three potential problems to consider:
Did you upload the files correctly?
Log onto the production server and look at the timestamp of the uploaded files. Do they match your expectation? Consider opening the files in production to see if they contain your latest changes.
Do you have a caching or compiling system in place?
While PHP is not compiled by default, there are tools available that allow you to compile it, and other tools that allow you to cache the output of the scripts. Ask your server administrator if any of these tools are being used.
Do your changes perform as expected?
Finally, check to see if your changes are in production, but not operating in the way that you expect.
So I have been given the task of upgrading one of our companies' old websites that is based on 1.5 to something newer (because a second site of ours on the same version just got hacked).
I know some php and some other web stuff, but I'd never used Joomla.
I have setup a lamp server on a local VM (ubuntu) for me to test it all out on, then upload the upgraded version as is suggested. My problem now is that I know the permissions are not correct because when I tried installing Akeeba Backup, it kept throwing errors such as "could not copy to /var/www/components and /var/www/administrator etc. I went in and chmod'd those 2 (and then the rest of www because of more errors) to 757 (from 755 for the most part) - which i know at that point might as well be 777. Then when I've tried to use Kickstart to restore from the JPA file I have, it just right away throws an error "could not create j_backup/ folder".
I know this slackening of all permissions on the root folder is wrong, but it was the only way to get it to 'work', which it's not even now, so my question is what did I do wrong in the setup and how do i fix it? I'm not great with Linux, but I'm thinking I have to make PHP owner of www? is that right? or terrible practice?
The other issue I see now is that I just installed the latest php and everything and I see Akeepa says not to use php 5.4... not sure how much of a problem that's going to be....
Some direction would be great because I'm more than a little lost.
Thanks!
This is certainly a headache. Most often, as you stated, the issue is the ownership of the files on your server. Files uploaded via FTP will be owned by your FTP user and may not be editable by the Apache/PHP user. Similarly, files created by installing extensions in Joomla! will be owned by the Apache/PHP user and your FTP user will not be able to modify them. Here is an article discussing the problem with a couple of possible solutions:
http://docs.joomla.org/Why_can%27t_you_install_any_extensions%3F#File_ownership_advice_from_ianmac
In the past, I have used an Apache Module called suPHP (http://www.suphp.org/Home.html) to solve this problem and keep it from reoccurring. suPHP executes PHP scripts with the permissions of their owners.
As for file permissions other than ownership, please refer to the Joomla! documentation for the correct settings: http://docs.joomla.org/Verifying_permissions. One quick way to handle this (if you can install extensions after correcting the ownership issue) is to use the AdminTools extension (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087). One of its tools ‘fixes’ the file permissions on your server by resetting them to the Joomla! default.
Good luck!
I want to update a Magento 1.4.2.0 to 1.6.x.y. instead of the latest version 1.7.x.y
There are many articles on how to update a Magento installation to the latest version, but that´s not what I want. There are some forum threads where people are asking how to update to a specific version, but those all don´t sport a solution.
It seems like it is only possible to unpack the tar.gz of the specific version, but it is not possible to use the command line tool, i.e.
./mage config-set preferred_state stable
./mage upgrade-all --force
Is there a way to use the command line tool to update to a specific version?
Two different ways of handling this, 1) Manually...
From my experience, what you end up doing is scrapping Magento Connect (which often is the source of all evil, when you've had it do partial upgrades two or three times in a row), downloading the whole package from the download archive (you have all the versions available from there on the Release Archives tab), unzipping them to a directory and then either on the server, copying them into your Magento root directory or from a remote workstation, ftp/scp uploading them to the server Magento root directory.
If you're serious about running Magento, you will have a development server that you do this to several times to find out where all the upgrade breakages are so you can weed out busted templates, detect forgotten core modifications, curse third party modules that don't survive, etc. It's really important to do this if you're depending on that e-commerce site for your income as intense suckage occurs when you aren't ready and sink the live site.
If you've modularized all your module overrides, created your own skin folders and custom template or used a well written template from a developer, it truly is just simply dumping the new version files on top of the old version files and overwriting everything (only after disabling all Magento caching and the compiler if you were using it and manually deleting all var/cache--? folders).
If, however, you've modified any of the files you are overwriting, you are in a world of hurt because you didn't do things properly.
Also, you have to deal with upgrading third party modules to work with the new version.
Then before committing the live site, backup all Magento application files and do a database dump.
2) Or use the command line tool as follows...
Since the original question was, "can you use the command line tool?" yes you can. Once you have the file saved from the download archive, use the following:
./mage install-file /home/login-name/path-to-download-file/magento-1.5.x.x.tgz
I've also used this on various module packages to inspect the contents. The mage command has a download only, download the package file, inspect the contents. If you like what it does, install it.