Moving site back to local - errors galore

[Liam88]

Hello all,

Ended my hosting and want to move my site back to local. I have downloaded my DB and relevant folders.

I'm just using Xampp for this which is up and running correctly. Tested with a fresh install of PW.

Done the following process:

1. installed fresh PW with created DB
2. Replaced folder items with existing website
3. dropped installation DB tables
4. Imported website DB
5. Adjusted config DB credentials to match.

Any direction on what these are? Unfortunately, little knowledge on these elements so direction is much appreciated.

TIA 
 

[bernhard]

There is no "blank" keyword in PHP

Try this:

if($page->hp_content_rep != "")

[Liam88]

5 hours ago, bernhard said:

There is no "blank" keyword in PHP

Try this:

if($page->hp_content_rep != "")

Thank you. I have now changed this out. Interestingly I didn't have this flag as an error when live.

I have also sorted the depreciated error by using Xampp with php 7.

Although that error is sorted (and there may be a few more I'll pick up) I'm mainly getting these ones below everywhere.

All of these were working correctly on live and even on the old local. 

This is line 28

 

[AndZyk]

Hello @Liam88,

you probably see these errors now, because you have enabled the debug mode of ProcessWire on your local copy or XAMPP has display PHP errors enabled.
I think on your live server display PHP errors is disabled and you should have not enabled the debug mode of ProcessWire.

The error you get now is, when you try to output a property of something that is not set.
You should first check if something exists, before you try to access the properties:

<?php
if ($page->header_image) {
	// Do something
}

If there is no image, then you cannot access the properties "url" or "description" and get the errors.

Regards, Andreas

[Liam88]

8 hours ago, AndZyk said:

Hello @Liam88,

you probably see these errors now, because you have enabled the debug mode of ProcessWire on your local copy or XAMPP has display PHP errors enabled.
I think on your live server display PHP errors is disabled and you should have not enabled the debug mode of ProcessWire.

The error you get now is, when you try to output a property of something that is not set.
You should first check if something exists, before you try to access the properties:

<?php
if ($page->header_image) {
	// Do something
}

If there is no image, then you cannot access the properties "url" or "description" and get the errors.

Regards, Andreas

Thank you Andreas.

Definitely noticing more issues since moving from live to local. Little elements like I have <? instead of <?php which worked on live but not in local.

Would you say that anything like the img example above should be within ifs to reduce errors?

[AndZyk]

12 hours ago, Liam88 said:

Little elements like I have <? instead of <?php which worked on live but not in local.

Yeah, although the short tag <? seems nice, I have read that you should avoid it, because it has to be enabled on the server and XML also uses <?.

12 hours ago, Liam88 said:

Would you say that anything like the img example above should be within ifs to reduce errors?

Every field that you didn't make a required field I would add an if condition, because it could be potentially empty. ?

[bernhard]

Quote

There must be a clear distinction between the PHP short tag (<?) and shorthand echo tag (<?=)

The former is prohibited by the PHP Coding standard, mostly out of common sense because it's a PITA if you ever have to move your code to a server where it's not supported (and you can't enable it). As you say, lots of shared hosts do support shorttags but "lots" isn't all of them. If you want to share your scripts, it's best to use the full syntax.

Whereas the shorthand echo tag <?= cannot be disabled and therefore is fully acceptable to use.

I agree that <? is easier on programmers than <?php but it is possible to do a bulk find-and-replace as long as you use the same form each time.

I don't buy readability as a reason at all. Most serious developers have the option of syntax highlighting available to them.

As ThiefMaster mentions in the comments, as of PHP 5.4, <?= ... ?> tags are supported everywhere, regardless of shorttags settings. This should mean they're safe to use in portable code but that does mean there's then a dependency on PHP 5.4+. If you want to support pre-5.4 and can't guarantee shorttags, you'll still need to use <?php echo ... ?>.

Also, you need to know that ASP tags <% , %> , <%= , and script tag are removed from PHP 7. So if you would like to support long-term portable code and would like switching to the most modern tools consider changing that parts of code.

https://stackoverflow.com/a/200666

Thanks for forcing me to look that up, and I'm happy I'm safe with my preferred way of writing php using <?php and <?= ? 

Update 08/2022: Now my favourite way is using LATTE via RockFrontend: {$page->title} instead of <?= $page->title ?> ?