This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Install & configuration » Urgent - after deploying to...
expandshrink

Urgent - after deploying to Dreamhost, site is still trying to use local path

Urgent - after deploying to Dreamhost, site is still trying to use local path

Thursday 28 May 2015 10:01:26 pm - 8 replies

Hi,

I had a working site on my Macbook, using MAMP for my localhost.

Yesterday I uploaded it to a Dreamhost shared server. The site loaded up but without assets such as images, photos etc. When I attempted to run cache:clear and dump the asets, an error came up regarding IMAGEMAJICK and PEAR. I followed Dreamhosts guide to installing http://wiki.dreamhost.com/Image_Magick and PEAR http://wiki.dreamhost.com/PEAR as they are not automatically ready to use, and tested to make sure that it was working as stated in the wiki.

Next, I tried to run cache clear and assetic dump commands again through ssh and the error message appeared to be picking up my MAMP path to autoload.php rather than the path on the server. I cannot find where to change this, so that it will work. 

The error messages on my terminal are as follows:

php ezpublish/console cache:clear --env=prod --no-debug
Warning: require_once(/Applications/MAMP/htdocs/Sites/midnight/ezpublish/../ezpublish_legacy/autoload.php): failed to open stream: No such file or directory in /home/andpal20/midnightmagpie/withextras/midnight/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishLegacyBundle/EzPublishLegacyBundle.php on line 39
Fatal error: require_once(): Failed opening required '/Applications/MAMP/htdocs/Sites/midnight/ezpublish/../ezpublish_legacy/autoload.php' (include_path='.:/home/andpal20/pear/share/pear') in /home/andpal20/midnightmagpie/withextras/midnight/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishLegacyBundle/EzPublishLegacyBundle.php on line 39

 

and when i go to load up the frontpage of the website it says:

Warning: require_once(/Applications/MAMP/htdocs/Sites/midnight/ezpublish/../ezpublish_legacy/autoload.php): failed to open stream: No such file or directory in /home/andpal20/midnightmagpie/withextras/midnight/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishLegacyBundle/EzPublishLegacyBundle.php on line 39

Fatal error: require_once(): Failed opening required '/Applications/MAMP/htdocs/Sites/midnight/ezpublish/../ezpublish_legacy/autoload.php' (include_path='.:/home/andpal20/pear/share/pear') in /home/andpal20/midnightmagpie/withextras/midnight/vendor/ezsystems/ezpublish-kernel/eZ/Bundle/EzPublishLegacyBundle/EzPublishLegacyBundle.php on line 39

 

I am so close to having this up online but this has got me stumped!

Any help gratefully accepted

 

Barry

Friday 29 May 2015 12:19:47 am

Hello Barry,

You can clear all caches manually (in new stack) by removing all files within the /path/to/ezpublishrootdir/ezpublish/cache/dev/* and /path/to/ezpublishrootdir/ezpublish/cache/prod/* directories. This might help solve part of the problem.

Did you upload the complete ezpublish_legacy directory to the remote server? For your use case, this is part of the source code installation is required.

eZ Publish is smart enough to not store the path to the installation within the installation (re: yaml settings, in ini settings, database content or eek php code) but then compiled caches are another matter entirely.

The lesson to learn here is to *always* clear all caches when migrating eZ Publish installations between servers (like dev to production). I prefer to clear caches before or just not transfer the cache dir file content when migrating.

I hope this helps!

Cheers,
Heath

Modified on Friday 29 May 2015 12:22:04 am by // Heath

Friday 29 May 2015 2:21:23 am

Hey Heath

You have come to the rescue again! you were quite right about those cache files needing to be deleted. That worked a treat to get rid of the MAMP / pear error.

Unfortunately I do have a follow on error from this. The page has come up (partly as expected) at www.midnightmagpie.co.uk/index.php/magpie  but it is still not picking up the images and therefor I assume not any other assets.

Now when I attempt to install the assets I get the following readout:

 

 

 

$ php ezpublish/console assets:install --symlink  web
Installing assets as symlinks
Installing assets for Symfony\Bundle\FrameworkBundle into web/bundles/framework
  [Symfony\Component\Filesystem\Exception\IOException]
  Failed to remove file "web/bundles/framework".
assets:install [--symlink] [--relative] [target]

 

 

 

 

Likewise, when I try to dump the assets I get:

 

$ php ezpublish/console assetic:dump --env=prod --no-debug
Dumping all prod assets.
Debug mode is off.
17:19:24 [file+] /home/andpal20/midnightmagpie/withextras/midnight/ezpublish/../web/js/e42d145.js
  [RuntimeException]
  The source file "/home/andpal20/midnightmagpie/withextras/midnight/ezpublis
  h/../web/extension/ezjscore/design/standard/lib/yui/3.17.2/build/yui/yui-mi
  n.js" does not exist.
assetic:dump [--forks="..."] [--watch] [--force] [--period="..."] [write_to]

 

 

 

 

 

So it seems to try to install / dump the assets but is unable to.

There must be another setting for this, to be able to use that command in a prod environment, but I cannot work it out

 

Thanks again Heath

 

Barry

Friday 29 May 2015 2:26:00 am

Also, the admin section has no styling and looks like an early 90's website, with white background, black writing and blue hyperlinks. lol

is there additional cache folders that need clearing for this?

Friday 29 May 2015 3:09:45 am

Hello Barry,

As I'm sure your now aware, you have asset 404 errors on the page load (thank you for sharing the url to the siteaccess in question; that helps). You can confirm this problem by loading the page and reviewing the 404 errors in the web browser console.

Now you should know that if you can't install assets (which errors I think because of permissions related problems) then you certainly can't dump assets.

Also it is in your best interest to use the '--relative' command line argument when installing assets (which uses relative symlinks instead of absolute path symlinks). Because as you indicated in past posts you did not use this option previously now all your existing asset links are absolute and thus invalid .. also your user and group file and directory assignments are for your dev server host and not the prod server which does truly need to be fixed. Please use relative paths for your symlinks by default instead of absolute symlink paths when working with / using symlinks (this is another unix best practice).

Like most web apps the owner should be the same user as the user running the webserver processes and the group should be the same primary group as the webserver user* (the group can be many things but in general this is the best practice recommendation). Also if you ever need to do things like alter any files in the installation on prod (this happens) you want to use sudo to do those things as the webserver use and / or ensure your user is part of the webserver's user group.

This can be more difficult in a shared server setting where your hosting provider is usually the only one who can change file / directory user/group ownership / assignments, etc. Which can be even more problematic to deal with / maintain when performing maintenance or even supporting a site once the very first deploy is completed.

In a dedicated hosting context, you have full control to do things the right way, the first time, beforehand to avoid potential bunny trail problems that never need to happen (cause they tend to happen again when not done the right way the first time, and 'Beyond 2000'). This is just one of many reasons I only recommend dedicated hosting solutions when deploying eZ Publish.

So my other recommendation is that you change the ownership and group assignments of all files within the installation (recursive).

See the official instructions show that relative asset installation is the recommended best practice here: https://doc.ez.no/display/EZP/Installing+eZ+Publish+on+a+Linux-UNIX+based+system#InstallingeZPublishonaLinux-UNIXbasedsystem-Before5.2:Linkassets<5.2

I think the quickest solution to the asset installation error would be to remove the asset symlinks which already exist and then re-install them.

This (I think) will involve removing the following symlinks:

  • web/var
  • web/share
  • web/extension
  • web/design
  • web/bundles/ezdemo
  • web/bundles/framework
  • web/bundles/sensiodistribution
  • web/bundles/tedivmstash
  • web/bundles/whiteoctoberpagerfanta

Then (after you have reset all files ownership and group assignments to match the webserver). Then use sudo to install assets (and dump assets) as the webserver user.

This solves the problem properly today and ensures (I'm very serious about this part now) much less future problems (if you don't, you will one day have more problems) and potential problems (things that might happen, due to lack of experience and proper best practice adherence). 

I hope this helps!

Cheers,
Heath

Friday 29 May 2015 3:36:43 am

Thank you Heath.

I have learnt a hell of a lot just from that short passage!I think I understand that all much better. I appreciate you takin the time to help me.

One thing I cannot find though, is HOW to remove symlinks.

Friday 29 May 2015 11:52:28 pm

Hello Barry,

I'm glad your learning! Your very welcome. I'm happy to be able to help you.

Apologies for my late reply, I was pulled away from the internet today big-smile.gif Emoticon

Though to be honest, you could have googled, "how to remove symlinks".

https://www.google.com/search?q=how%20to%20remove%20symlinks&rct=j

The first result is a helpful answer: http://stackoverflow.com/questions/210120/remove-a-symlink-to-a-directory

It's just that removing symlinks is not eZ specific and their are tens of thousands of better places on the net to get that answer.

In short you remove symlinks the same way most people remove any other kind of file, by using the 'rm' command big-smile.gif Emoticon I use 'rm -vf' myself most commonly and I always make sure not to use a trailing slash. Here is a more specific (related) example:

rm -vrf web/bundles/ezdemo;

Notice I omitted a trailing slash after the 'ezdemo' string and used the ';' char to indicate the end of the command which ensures that the command is ended and nothing else accidentally added to the end of the command line string is included or accidentally affected.

I hope this helps! Have a great weekend!

Cheers,
Heath

Monday 01 June 2015 2:09:31 am

Yes you were totally right Heath.

I had to start the upload process again. I removed the contents of the web/bundles folder on my local machine. Next I compressed my project into a zip file, uploaded and unzipped. Then I cleared the cache, and ran :

 

php ezpublish/console assets:install --symlink  --relative web

php ezpublish/console asseic:dump --env=dev web

 

and then the site was ready to use in the dev environment.

 

Thanks for your help again!

Monday 01 June 2015 11:05:42 am

Hello Barry,

I'm very pleased I was able to you help you solve the problem(s).

Can you login to share.ez.no and then click the checkbox at the top of your original post near the title? It is the box with the checkbox inside. It turns green when you have clicked it correctly.

Doing this indicates your question has been solved.

Thanks again for your continued support!

Take it eZ!

Cheers,
Heath

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from