Tribe Support

Tribe Support's Topics

Unknown Person

May 26 2015

Composer update

Just ran a composer update for my live site.Watching composer do its job, all appeared to be in order.

Loading composer repositories with package information

Updating dependencies (including require-dev)

- Installing anahita/anahita (4.1.0)

Downloading: 100%

Writing lock file

Generating autoload files

And that's where it stopped, and returned to

So.., my project was not updated at all.

Do I need to put require 'vendor/autoload.php', in json, or should I be using composer.phar install instead of update?

I double checked composer.json and composer.lock and they look ok to me.

What am I missing?

I await your reply with giggly anticipation :-)

composer update alone should work. Try composer self-update to update your composer perhaps. Also please use gist for posting code snips.
Unknown Person
May 26 2015 Permalink
Oops will do. Thank you.
Composer is fully updated.
Update still stops at 'Generating autoload files'.
are the file and directories writable by the system?
Unknown Person
May 26 2015 Permalink
Yes, they are writable by the system.
ok do:

sudo composer update --verbose

and that should give you a more descriptive error message
Unknown Person
May 26 2015 Permalink
Ok, did that.
Still hangs at 'Nothing to install or update'
Generating Autoload files...

No further messages.
Google the error. This probably happens to other php apps that use composer too.
Unknown Person
May 26 2015 Permalink
Loading ...

>Still searching Google....
From what version are you upgrading from? How much memory do you have on your server?
Unknown Person
May 27 2015 Permalink
Upgrading from 4.0.4 and memory was 512m and i've changed it to -1 unlimited.
Surprisingly, google was no help at with this. Plenty info out there for windows users though.

Reinstalled composer.phar into myproject.
Update successful? Don't know why, I really didn't do anything different.

Unfortunately, during the 'update', composer deleted anahita 4.0.4 and 'installed' 4.1.0' rather than simply updating new or changed components etc.

So, although the database user accounts are still there, all their website content and interactions are gone forever.
The configurations have reverted back to their original states. For example, the site template is now style1 instead of style2. It may as well be a completely new installation.
I'm sorry to hear that. Making a database backup is always recommended before upgrading.

Had you done any modifications in your 4.0.4 installation? If yes, where?
Unknown Person
May 27 2015 Permalink
No modifications yet. I wanted to keep it simply until I understand server side configurations a bit better. Make that "A lot better". I've got to go back and recheck write permissions and ownership issues again, because although config is saveable without errors, no actual changes are made to brand name etc. Users are still there, mail function is still good.

So, the update didn't actually destroy the database. It just didn't fully connect with it. I can still log in to /administrator with the original credentials, so user accounts maybe salvageable.

Thing is, I haven't been able to log into the front-end yet. It seems that the base64 encoding for the 'return' in the login modal is wrong. I can change it manually, but I don't remember the correct url path to point it too.
The updated login modal 'return=' points' to http://mysite/search?term=
and the old one, which is on the html landing page, goes to the pretty url http://mysite/Dashboard which used to work just fine.
I know that it's a new topic, but could you please give the proper login link so that I can manually convert it to Base_64 format?
Hey, thanks for the time you've spent on this, I know it's a bit of a pain.
go to global config turn off cache, save, and turn on again, and save. That will clear your APC cache. That could be one issue. Also use database for the sessions.
Yes the return value has a bug and that issue has been fixed in the master branch.
Also the following commands will repair the broken symlinks:

php anahita site:symlink
Unknown Person
May 27 2015 Permalink
Thanks for that @Rastin :-)
Cache cleared, database is session handler. Glad the bug is fixed and thanks for the heads up on the symlink :-)
I'll solder on tommorrow.
Rastin Mehr liked this
Unknown Person
May 27 2015 Permalink
Has the params.ini been moved to a different folder? It used to be in templates/shiraz, but I don't have it there. If it can be found, i need to make it writeable, or do I need to recreate it?
login modal still not working even after the site:symlink repaired links.
just save the settings and it will be recreated. It would have been much safer if you had developed your own custom template and used Shiraz as a blueprint only. Put your custom template in the packages folder and it becomes recognized as yet another installable package. This way when you upgrade, your customization doesn't get overwritten. You can even host your custom packages on a different repository.
Unknown Person
May 28 2015 Permalink
It returns a 'failed to open file for writing', so it is not recreating it. Is that apache permissions issue again then? I've already done chown www-data:www-data and re-did, chown -R www-data:www-data where i thought it may be required.

Previously, I have had params.ini set to 'custom' aka style2. I had simply copied style1 and placed it into style2 hoping that it would be enough to avoid being overwritten when updating. I'll follow your advise for next time though, thanks. I'll try to host it on my own repo. And that's very cool by by the way :-)
That looks like a permission issue. The command chown -R www-data:www-data should fix it.

Powered by Anahita