• Resolved aajax

    (@aajax)


    I run test systems on my own computers in order to verify correct operation prior to migrating them to my hosting service. In this case, I also thought it was time to upgrade that underlying software in order to align better with my hosting service. Therefore, this issue is related to migrating a website that is functioning correctly when running on XAMPP 7.4.33 to XAMPP 8.2.12. I think those numbers correspond to the version of PHP that applies which seems to me to be the mostly likely source of the problem.

    The website in question is for displaying photographs. It uses WordPress along with the Photocrati theme that includes Nextgen plugins. It works correctly when operated using XAMPP 7.4.33. However, when I run an exact duplicate of the WordPress files and associated database on XAMPP 8.2.12 an error message gets displayed as follows:

    Warning: Undefined variable $header_style in T:\xampp\htdocs\DPGsite\wp-content\themes\photocrati\inc\customizer\settings\menus.php on line 2226

    I have inspected the file in question and I cannot find any code that would assign a value to that variable, which is why I suspect the problem is being caused by PHP. I would appreciate suggestions on how to proceed to correct the problem.

Viewing 3 replies - 1 through 3 (of 3 total)
  • In your other post you refer to using WordPress 3.2 when the current version is 7.0 You may need to check if the fault persists on an updated WordPress.

    Plugin Support Mihai

    (@mceban)

    Hi @aajax,

    Thanks for reaching out and sorry for the inconvenience.

    As you’re using a premium Photocrati theme, our support team is best equipped to assist you with this warning. It may be related to an undefined variable in the code, and while it isn’t critical, we want to ensure it is documented and fixed.

    Please open a ticket at Photocrati Support and include all the relevant details. Our team will look into the issue and provide further assistance.

    Thanks!

    Best regards,

    Thread Starter aajax

    (@aajax)

    Per mbsharp, the problem arose initially on WP 6.2 but only for the instance running on PHP 8.2.12. Things work as expected/desired with the same instance running on PHP 7.34.33. I did create another instance in order to see if the WP version may have been a factor but the problem still exists.

    The reason this is happening on my test systems is that I like to avoid such problems arising on my operation instance which is running on my hosting service. In that I wanted to test the upgrades before changing the operational system. However, in this case it is not the software that I have any control over which seems to be causing the problem. My hosting service does allow choosing between a few different versions of PHP but I do think that eventually I’ll need to update.

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.