Upgrade to latest source

[SLiCK_303]

If any of you would like to test out the latest source, I wrote a guide to do it, just goto https://thirtybees.com/developer-blog/upgrade-a-1-0-3-site-to-1-0-4-latest-source/ . It's easy to do, if you have a tb site you setup yourself, you should be able to follow this and get it working. Come on people, lets help test this thing!

[Baarssen]

you did a great job @SLiCK_303 However i dont use this way, i appreciate your devotion to the community ?

[Beeta]

I'm upgrading right know so I can report some bugs if found.

[SLiCK_303]

I hope it goes well, the more testers the better.

[Beeta]

ok, I just finished following the article, the front end is working but I'm getting a 500 error logging in to the back office.

This is the error on nginx logs:

2018/02/07 10:01:29 [error] 2468#2468: *2921 FastCGI sent in stderr: "PHP message: PHP Fatal error: Class 'ModuleStats' not found in /home/domain/domains/new.domain.com/public_html/modules/statsmodule/statsmodule.php on line 551" while reading response header from upstream, client: 79.12.245.69, server: new.domain.com, request: "GET /admin3892b5trc/index.php?controller=AdminModules&token=29fb394ab861c81bbeb0c6d5ddfc9d63 HTTP/2.0", upstream: "fastcgi://127.0.0.1:8012", host: "new.domain.com", referrer: "https://new.domain.com/admin3892b5trc/index.php?controller=AdminDashboard&token=ac94432f16559f611a6f76f6ae98a0a6"

I double checked the statsmodule and I confirm that is uploaded in modules dir. Permissions seems ok.

Another error on error.log is: 2018/02/07 10:06:28 [error] 2468#2468: *2921 FastCGI sent in stderr: "PHP message: PHP Notice: Undefined index: lazy_load in /home/domain/domains/new.domain.com/public_html/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 76

I'm on a Debian 8: php 5.6.x (phpfpm) nginx 1.10.x

[lesley]

Are the permissions set correctly on the module?

[SLiCK_303]

I find it strange you are getting a FastCGI error when you are on fpm. Have you tried changing your php to FastCGI and see what happens?

Have you tried just deleting the statsmodule folder? You'll need it after you get things working, but just for now....

Before the migration to 1.0.4 did you get your cloned site fully working?

[Beeta]

@lesley said in Upgrade to latest source:

Are the permissions set correctly on the module?

I chmodded to 775 directory and files and I'm getting the same error.

@slick_303 said in Upgrade to latest source:

I find it strange you are getting a FastCGI error when you are on fpm. Have you tried changing your php to FastCGI and see what happens?

It's a configuration in Virtualmin, I'm on FPM (TCP connection and not Socket)

Have you tried just deleting the statsmodule folder? You'll need it after you get things working, but just for now....

Now I deleted and the error about is not logged anymore... but I still get a 500 error page on TB back office (without specific info about the error).

Before the migration to 1.0.4 did you get your cloned site fully working?

Yes was fully working.

Now I'm getting: 2018/02/08 01:12:59 [error] 27709#27709: *11509 FastCGI sent in stderr: "PHP message: PHP Notice: Undefined index: lazy_load in /home/domain/domains/domain.com/public_html/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 76 PHP message: PHP Notice: Trying to get property of non-object in /home/domain/domains/domain.com/public_html/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 76 PHP message: PHP Notice: Undefined index: lazy_load in /home/domain/domains/domain.com/public_html/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 76 But I think is related to browsing the front end.

[SLiCK_303]

Are you using the default theme? If not you can add this to the bottom of your themes config.xml, right before the last line, <lazy_load>1</lazy_load> <high_dpi>1</high_dpi> <webp>1</webp> as this error is happening in the backend, I find it hard to believe it will help, but you can try. I assume this issue needs to be addressed by a developer...

[Beeta]

@slick_303 I'm using the default theme and the last four rows are:

<lazy_load>1</lazy_load> <high_dpi>1</high_dpi> <webp>1</webp> </theme>

[Beeta]

this is my nginx configuration:

``` server { servername new.domain.com www.new.domain.com; listen xxx.xxx.xxx.xxx; root /home/domain/domains/new.domain.com/publichtml; index index.html index.htm index.php; accesslog /var/log/virtualmin/new.domain.comaccesslog; errorlog /var/log/virtualmin/new.domain.comerrorlog; fastcgiparam GATEWAYINTERFACE CGI/1.1; fastcgiparam SERVERSOFTWARE nginx; fastcgiparam QUERYSTRING $querystring; fastcgiparam REQUESTMETHOD $requestmethod; fastcgiparam CONTENTTYPE $contenttype; fastcgiparam CONTENTLENGTH $contentlength; fastcgiparam SCRIPTFILENAME /home/domain/domains/new.domain.com/publichtml$fastcgiscriptname; fastcgiparam SCRIPTNAME $fastcgiscriptname; fastcgiparam REQUESTURI $requesturi; fastcgiparam DOCUMENTURI $documenturi; fastcgiparam DOCUMENTROOT /home/domain/domains/new.domain.com/publichtml; fastcgiparam SERVERPROTOCOL $serverprotocol; fastcgiparam REMOTEADDR $remoteaddr; fastcgiparam REMOTEPORT $remoteport; fastcgiparam SERVERADDR $serveraddr; fastcgiparam SERVERPORT $serverport; fastcgiparam SERVERNAME $servername; fastcgiparam HTTPS $https; location ~ .php$ { tryfiles $uri =404; fastcgipass 127.0.0.1:8012; } listen xxx.xxx.xxx.xxx:443 ssl; sslcertificate /home/domain/domains/new.domain.com/ssl.cert; sslcertificatekey /home/domain/domains/new.domain.com/ssl.key;

## rewrite rules for prestashop/thirtybees
location / {
    index index.php;
    rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;
    rewrite ^/([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$1$2.jpg last;
    rewrite ^/([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$1$2$3.jpg last;
    rewrite ^/([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$1$2$3$4.jpg last;
    rewrite ^/([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5.jpg last;
    rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.jpg last;
    rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.jpg last;
    rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.jpg last;
    rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.jpg last;
    rewrite ^/c/([0-9]+)(-[_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2.jpg last;
    rewrite ^/c/([a-zA-Z-]+)(-[0-9]+)?/.+\.jpg$ /img/c/$1.jpg last;
    rewrite ^/([0-9]+)(-[_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2.jpg last;
    try_files $uri $uri/ /index.php?$args;
}

}```

[lesley]

Did you make sure you copied over the admin directory? You needed to rename it from admin-dev

[Beeta]

@lesley said in Upgrade to latest source:

Did you make sure you copied over the admin directory? You needed to rename it from admin-dev

I deleted the old admin directory and then renamed "admin-dev" to the old directory name.

Now I went back to a backup, I'm going to try again next week.

[Beeta]

I tried again and now it worked like a charm! I think that the first time I missed a step.

[SLiCK_303]

Glad you got it working...welcome to 1.0.4, test away, and give them some feedback...

[DaoKakao]

What's wrong with update via git pull + composer update if i have ssh access?

[Pedalman]

Hello I was so bold to run my live shop with 1.0.4 since you made this post Slick. I had no issues and all was more than fine for me. Anyhow I stopped looking for updates since end of Januara I think. Now, 1.0.4 is topical to the latest and public. So great news.

But how can I update form pre 1.0.4 to the latest without issues?

[rubben1985]

Hi @pedalman you can follow this post https://thirtybees.com/blog/version-1-0-4-has-been-released/

[Traumflug]

What’s wrong with update via git pull + composer update if i have ssh access?

This certainly works with some extra care:

• The database upgrade script should be run nevertheless.
• Having an admin folder named admin-dev is fairly easily predictable, removing a level of security (password security is still there). Having a different name brings a folder name mismatch.
• Having the installation folder in place ... well, anybody can re-install the shop.

[Traumflug]

But how can I update form pre 1.0.4 to the latest without issues?

The same way you upgrade from 1.0.3. @rubben1985 posted the link.

[DaoKakao]

@traumflug I beleive, all this extra steps worth not much compared to (re)installation from scratch :) Would it be nice to make a blog post about that kind of install/upgrade?

Could you gime more info about database upgrade sql script run, please? I didn't found it on github...

[Traumflug]

I didn’t found it on github…

From the upgrade blog post:

This 'here' in bold letters is a link. Click on it :-)

[Traumflug]

I beleive, all this extra steps worth not much compared to (re)installation from scratch ?

An installation from scratch means a new, empty database. All products, all product pictures, all customers, all orders gone. If you can afford this, sure, go ahead.

Doing a fresh installation, then pulling over the data is probably possible, but much more complex than the recommended upgrade process. If you want to try: backup the database in the old shop and keep that old shop running. Then restore that database in the new shop. Then copy over all files in img/, upload/ and download/. Then run the upgrade SQL query. Then cross fingers I didn't forget something in this list. It's asking for trouble.

[DaoKakao]

My point is, that for users familiar with shell/sql/git it is quite fast process, not so trouble-generating. Also it allows to keep your sources up-to date as frequently as you wish just with one command, within boundaries of one version of course.

And, of course, any "asking for trouble" could be mitigated significantly by doing backups.