I have this website i am building with Joomla! 2.5. It is a shopping cart and i was building it on my Xampp bu the minute i uploaded it to my server, it doesn't show anything on the front page. The admin section is okay but the front page doesn't show anything. When i turn on error reporting for development, i get the below error.
Strict Standards: Only variables should be assigned by reference in /home/sites/mydomain/public_html/beta/plugins/system/jblibrary/jblibrary.php on line 26
Strict Standards: Only variables should be assigned by reference in /home/sites/mydomain/public_html/beta/plugins/system/jblibrary/jblibrary.php on line 55
Strict Standards: Only variables should be assigned by reference in /home/sites/mydomain/public_html/beta/plugins/system/jatypo/jatypo.php on line 55
Fatal error: t3import not found object: core.libs.browser in /home/sites/mydomain/public_html/beta/plugins/system/jat3/jat3/core/common.php on line 33
I took a look at one of the files throwing the error and the line below seemed like the problem.
$document =& JFactory::getDocument();
I have tried to modify it to;
$document = JFactory::getDocument();
But the error is still thrown. I have also tried switching the PHP versions but the error persists. I just can't seem to figure out why the site is working on my localhost and not on my server. Any ideas? Thanks
The last line of your errors tells you why Joomla is white-screening. The Strict standards warnings are just warnings, they don't stop execution.
Fatal error: t3import not found object: core.libs.browser in /home/sites/mydomain/public_html/beta/plugins/system/jat3/jat3/core/common.php on line 33
A Fatal error is just that, it can't be recovered from.
In this case, your website is crashing because the front-end Joomla is trying to load a T3 based template that in turn tries to load the T3 framework which needs /jat3/jat3/core/common.php and it can't find it on the live server.
If it's working on your Xampp setup then it probably means you didn't move it correctly/move all the files or set the paths up correctly in the configuration.php.
The easiest and safest way to move a site from development to live is to use Akeeba Backup in conjunction with Akeeba Kickstart which will package your development site into a single file and include an installer in it. Then you can upload the backup file and the kickstart file to your server and follow the kickstart documentation to "restore" your development version to the live server.
i had just encountered this error when i deployed my joomla instance from windows to a linux server. t3import is looking for /core/libs/browser.php but the actual filename is Browser.php. Linux is case-sensitive so it didn't find the correct file. i just renamed Browser.php to browser.php and it worked fine.
Related
I posted the solution as an answer
I'm running into an odd issue while migrating some PHP code to a new server. The old server is running PHP 5.3 (x86) and the new server is running PHP 7.0 (x64). Both are running on IIS 7.5.
The code causing the issue has been in production without issues for almost three years. It runs fine on the current production server as well as two development systems. All three are running PHP 5.3 (x86).
These errors do not occur when I use PHP 5.3 (x86) on the new server.
A shared file (named _common_funcs.php) contains common functions that are called from many scripts. Since some of these scripts can interact I use require_once('_common_funcs.php') to include the file. This is approach pretty basic.
On the new server the first time a the script runs it generates a 'Cannot redeclare' error. Refreshing the page does not display the error - it displays the page as expected. For example:
//localhost/app/display_account.html?account=123456 generates the error.
//localhost/app/display_account.html?account=123456 again does not display the error.
Restarting the IIS server causes the error to be generated again on the first run.
Now for the odd part. Note the capitalization of the drive letters in the error below:
Cannot redeclare acct_has_graduated() (previously declared in D:\app_directory\includes\_common_funcs.php:2061) in d:\app_directory\includes\_common_funcs.php on line 2061
If I hardcode the full path in one require_once() line, and use a lowercase 'd', then the error in the log will swap the capitalization. This results is 'd:\app ...' and 'D:\app ...'.
If I hardcode both calls that happen to get called when this script runs with the error is not generated no matter what mix of capitalization I use.
And to make this just a little more interesting, the acct_has_graduated() function is the last function in the _common_funcs.php file. But if I disable OpCache in php.ini I get the following error:
Cannot redeclare update_ledger() (previously declared in D:\app_directory\includes\_common_funcs.php:7) in d:\app_directory\includes\_common_funcs.php on line 42
Two things of note: update_ledger() is the first function in the _common_funcs.php file, and "line 42" is the closing bracket of the update_ledger() function (line 7 is the declaration).
If anyone can point me in the right direction on this I would greatly appreciate it.
Solution
I found the issue and the file is absolutely being included twice. This happens under a specific set of circumstances. It affects PHP 7.0 but does not affect PHP 5.3. I did not test any other versions of PHP.
This scenario is certainly an outlier, but here it is:
I have a directory symlink from c:\inetpub\wwwroot\app_location to d:\app_location.
The IIS configuration for this site points to c:\inetpub\wwwroot\app_location.
The application's configuration file defines the include_path using c:\inetpub\wwwroot\app_location as the base.
All the files for this site are located in d:\app_location.
Using the configuration above all entries in the application's log files (tracking, audit, error and backtrace) show D:\app_location as the base location of all files.
Calling require_once() on a file more than once, while allowing the include_path to resolve the location of the file in one or both of the calls, generates the 'Cannot redeclare' error. The error reports the opposite capitalization of the 'D:' drive letter (see error text in the post above).
Changing the base of the include_path (#3 above) to d:\app_location resolved this issue.
The question is very simple.
require_once('D:\file.php');
require_once('file.php');
will run twice, because you included the absolute path!
Solution
Use relative path
require_once('../core/file.php');
I'm using Joomla 3.8 to manage our community website (on the side pro bono). Everything was going well until I noticed an article with a padlock icon in the administration. I applied Global Check In, which unlocked the article. But now I find that I am unable to add or edit articles. Please see screenshot below:
The website is running on PHP version 5.6.31, with web server Apache.
How do I fix the problem? Is there any code I need to tweek?
This is how I determined the source of the problem. On the administration, I raised the error reporting to maximum:
Global Configuration > Server tab > Error Reporting (changed from System Default to Maximum)
I saw the following errors:
Notice: Undefined variable: plugin in */home5//public_html/plugins/system/connectdaily/connectdaily.php on line 42
Fatal error: Call to a member function logError() on null in /home5//public_html/plugins/system/connectdaily/connectdaily.php on line 42*
I deactivated the connectdaily plugin. The fix worked. I am now able to add and edit articles again.
I am still not sure where the connectdaily plugin is used for. If ever the website will need it, I will just reinstall the plugin.
When I try to install Opencart V3.0.2.0 in Linux server, getting following error message.
Fatal error: Internal Zend error - Missing class information for in
/system/storage/vendor/twig/twig/lib/Twig/ParserInterface.php on line
31
I am not able to start my installation process. Any idea, Please help.
While this is not guaranteed to work, but since few people reported that they have been able to solve it disabling APC I would give it a try.
If you want to disable Alternative PHP Cache (APC), you can do so by modifying your PHP initialization file file.
Using your hosting account's editor (Web & Classic / cPanel / Plesk), open your website's PHP initialization file.
Note: I recommend backing up your PHP initialization file file before modifying it. You can do this by copying and renaming it in your file manager.
On a new line, type apc.enabled=0
Save your changes.
At the moment, I am installing PHPBB 3.0.10 and am having this error:
Strict Standards: Non-static method utf_normalizer::nfc() should not be called statically in C:\xampp\htdocs\PHPBB\includes\utf\utf_tools.php on line 1781
I have tried to find an answer for this on the PHPBB boards but have had no luck. I have a bit of background in PHP but don't understand static function calls from dynamic ones. I am using PHP v5.4.4, Apache 2.4.2 and Xampp 1.8.0, if any of that is of relevance. I am also running this on my localhost, not on a remote server.
To induce this error, all I am doing is installing PHPBB. Once I have inserted the Database settings and the Admin account settings, it comes up with this error and won't allow me to continue. I have no extensions installed (ofcourse).
Also, I have not been able to find the nfc function in the file specified. I am unsure as to whether it's in an include though. I also searched inside all files for "function nfc" (excluding quotation marks), but found nothing, and so am unable to use this: Strict Standards: Non-static method STemplate::assign() should not be called statically
. I am aware that this problem is common, and many people have claimed that a certain fix has worked for them, but I have been unable to apply these fixes because they were for earlier versions of PHPBB (i.e. 1.0.4).
I have been able to install PHPBB on localhost in the past, but not now. I currently have no working PHPBB installation.
Thanks for any help given.
I know this is outdated, however rather than suppressing the issue
If you want to properly fix this at the root of the problem,
Open up includes/utf/utf_tools.php
Go to ~line 1663
Replace
utf_normalizer::nfkc($text);
With
$utf_normalizer = new utf_normalizer();
$utf_normalizer->nfkc($text);
unset($utf_normalizer);
I'm still not sure why this hasn't been fixed in a proper release
go to your /includes folder and open up the startup.php
On line ~22 change the line
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
to
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT);
This may solve your problem =).
I run into a similar problem today after I updated to 3.0.12 and I think the proper solution is to make static all the functions in utf_normalizer.php instead of making non static all the calls to these functions.
BTW this is how it's done in phpbb 3.1.1
We have a silverstripe website that works ok in production on a centos webserver. I am asked to make modifications to this site and have to have a working copy on our internal Ubuntu dev server. The guy that did the website is long gone and no one knows this project.
I did the move, transfered the database and changed the config files to the new settings. Now whenever I start the site I get a full page or red errors:
FATAL ERROR: call_user_func_array() expects parameter 2 to be array, null given
At line 404 in /home/user/site/sapphire/core/ViewableData.php
call_user_func_array(Array,)
line 404 of ViewableData.php
ViewableData->XML_val(current_lang,,1)
line 4 of .cache.home.user.site.mysite.templates.Layout.PageAccueil.ss
include(/home/user/site/silverstripe-cache/.cache.home.user.site.mysite.templates.Layout.PageAccueil.ss)
line 197 of SSViewer.php
SSViewer->process(PageAccueil_Controller)
line 189 of SSViewer.php
SSViewer->process(PageAccueil_Controller)
line 296 of Controller.php
Controller->defaultAction(index,Array)
line 267 of Controller.php
Controller->run(Array)
line 22 of ModelAsController.php
ModelAsController->run(Array)
line 27 of RootURLController.php
RootURLController->run(Array)
line 104 of Director.php
Director::direct()
line 160 of main.php
As far as I know nothing is "weird" on our dev server and other frameworks (zend framework or even wordpress) work perfectly.
This is not with the latest version of silverstripe but trying to update it I ran into the same errors so I'd prefer have it work before updating it.
We are using silverstripe version 2.2.2.
Any helps or pointers are welcome!
edit: I did try to load the site with /dev/build/?flush=1 and /build/?flush=1 still get the same errors on theses pages. Also the cache files should be set correctly.
1) You might want to try ?flush=all (unless you've made any changes to the database, you don't need /dev/build)
2) My first guess would be the PHP version. Do you have the same version on both the old and the dev box? SS 2.2 doesn't work well with PHP 5.3 - if I remember correctly.
Running into issues when upgrading from 2.2 to 2.4 can happen - there were some changes but they should be relatively minor. If you haven't done the ?flush=all you might still get errors from the previous version.
Or you might even want to clear out the silverstripe cache directory manually (silverstripe-cache or if that doesn't exist a few directories down in /tmp). I always do that when copying my SS files from one server to another as old cache files can lead to very weird behavior...