I am getting the following error.
PHP Notice: Only variables should be assigned by reference in
/var/www/html/plugins/system/jxtcadminlock/jxtcadminlock.php
I am usig PHP 7.2
And the 39th line of the file(/var/www/html/plugins/system/jxtcadminlock/jxtcadminlock.php) is as below.
$mainframe =& JFactory::getApplication('admin');
I need to fix this without upgrading joomla.
First of all, this is just a notice. If you aren't going to fix your codebase manually to make it PHP/7 compliant you can just ignore it.
If I'm not wrong that's the old PHP/4 syntax, obsoleted in 2004, to deal with the fact that objects used to be passed by value rather than reference. It's quickly mentioned in the Migrating from PHP 4 to PHP 5.0.x guide.
Since PHP/5 you can drop the & sign altogether. However, it's very likely that this isn't the only compatibility issue.
Related
On an local XAMPP development environment I can access an object's property in PHP by calling:
$xmltemplates->$_POST['xmlmap']->sheet;
But on a live server I have to put the POST variable into a string so it works:
$gehmiraufdiekeks = $_POST['xmlmap'];
$xmltemplates->$gehmiraufdiekeks->sheet;
Do I need to fix alle the code or could it be a server configuration issue?
UPDATE:
I expected the XAMPP test environment to be at least PHP 7. So I only checked the server's PHP version which was 7. But when I doubled checked both PHP Infos, my local PHP version was 5.6. D'oh! So anyone who has this kind of problem: please update your code to PHP 7. ;)
Two things:
Production servers are configured (or should be) to hide error messages. That's why you're getting none. You need to either check the server logs or enable full error reporting.
I understand you refer to invoking variable properties without using curly braces, as in:
$key = 'bar';
var_dump($foo->$bar);
... rather than:
var_dump($foo->{$bar});
That's explained in the Changes to the handling of indirect variables, properties, and methods section of the PHP/7.0 migration guide (emphasis mine):
Indirect access to variables, properties, and methods will now be evaluated strictly in left-to-right order, as opposed to the previous mix of special cases.[...]
Code that used the old right-to-left evaluation order must be rewritten to explicitly use that evaluation order with curly braces (see the above middle column). This will make the code both forwards compatible with PHP 7.x and backwards compatible with PHP 5.x.
Actually, this is PHP version related. They changed this in PHP 7 so no one can mess up your script with a wrecked, unescaped string sent via POST forms.
On my development server, I installed PHP (5.5), MySQL and Apache. The hosting company only supports up to PHP version 5.3.27. I don't really work in PHP, often so I might be missing something obvious here, but my problems are the following:
CakeSession::read('User.stuff')['more_stuff']; // works on 5.5
CakeSession::read('User.stuff')['more_stuff']; // syntax error on 5.3... wat?!
I managed to fix the above issue by assigning CakeSession::read('User.stuff') to a temp variable, and then accessing more stuff with $tmp['more_stuff'].
However, I have a bigger problem. I can't seem to access model names by their model name in arrays returned from databases. Namely, the following code stopped working:
$some_model['ModelName']['model_field']; //works on 5.5
$some_model['ModelName']['model_field']; //warning about 'ModelName' being a non-existant index.
When I try $some_model[0]['model_field'] it works just fine.
Cheers!
EDIT: Ok, turns out < PHP 5.4 doesn't support subscripting return values. Still weird, but it explains the first problem.
As you found out, array dereferencing with function/method call expressions is only supported as of PHP 5.4, nothing special about it, it's simply a feature of newer PHP versions.
Your other problem is most probably not that string indices magically don't work anymore, but simply that the structure of the array you are accessing is different.
Where this difference might stem from? Pretty hard to tell without any context. You should provide some code that can be used to reproduce your situation, and you should also do some more debugging on your own, trace back the function call flow and check at which point the data becomes different.
I am using Smarty 2.6.9 and I am finding that I experience issues with the following block of code.
Copyright © {$smarty.now|date_format:'%Y'} CRMPicco. All rights reserved
The date generated by Smarty seems to be random, sometimes it's 8780, sometimes it's 1872...as I say, completely random.
What I am finding is this seems to be an environmental issue too, as it works in my development environment (CentOS 5.6) but is broken in a testing environment. Now, I realise this would point to a config issue on the testing environment but I am using PHP date functions all through the codebase and if it wasn't working i'd soon know about it.
I appreciate I may get suggestions along the lines of "if PHP date function works then send that through to your Smarty template", but there must be a way to do it in Smarty too?
Is this a bug in Smarty or a config issue?
It's a somewhat-known configuration issue, caused by $smarty->plugins_dir not being set correctly (or some other problem preventing access to that directory).
date_format is the name of a Smarty plugin, but it's also the name of a PHP function. If Smarty cannot locate its plugin it falls back to calling the PHP function, which expects a completely different set of arguments. The resulting breakage is what you see.
I have created a website 3 month ago. I uploaded it to internet and it worked(it still works there). Now I installed it in my local computer and trying to access it. However it prints the following error messages multiple times:
Deprecated: Assigning the return value of new by reference is
deprecated in C:\xampp\htdocs\ptr\xajax\xajax_core\xajax.inc.php on
line 1258
Strict Standards: Only variables should be assigned by reference in
C:\xampp\htdocs\ptr\xajax\xajax_core\xajaxPluginManager.inc.php on
line 269
I am using XAJAX framework and the errors have something to do with this framework. Since I haven't changed anything in the library files, I don't understand what the problem can be. Please help... I am freaking out
The framework you are using seems to be a little bit outdated and uses such constructs
$x = & new Classname();
The & before new is deprecated since PHP 5.0 (which is several years old now). With the introduction of E_DEPRECATED- and E_STRICT-messages it throws such a message now.
Unfortunately this kind of statement are deprecated from PHP 5. In your local machine you're running a version which is 5.3 while your server is running an older version. Thus, on your machine is thrown a E_STRICT error. To avoid this problem, you have to change lines like:
$node_obj =& new someClass($somearg, $moreargs);
into
$node_obj = new someClass($somearg, $moreargs);
Xajax 0.6 targets this and a couple of other issues. When the development on xajax 0.5 started many users were still trapped on PHP4 Webservers and this syntax helped maintain compatibility for PHP4 up to 5.2.x.
Xajax 0.6 can be found on https://github.com/Xajax/Xajax-Project
Though it's still beta, it's already pretty solid. Many deprecated function were dropped and the core was shrinked & optimized.
Previous comments fully explain the source of those warnings. Your website will work fine despite of them. But you can disable PHP error reporting, if you want to hide these messages - this manual may help you: http://complete-concrete-concise.com/web-tools/how-to-turn-off-display_errors-in-xampp
(UPD: For your local version only of course)
Im trying to compile phpurple. Im doing everything according to the documentation:
hxxp://phurple.php.belsky.info/ch02.html
but "make" gives me an error:
/myhomedir/phpurple/purple.c: In function ‘call_custom_method’:
/myhomedir/phpurple/purple.c:1370: error: ‘zend_fcall_info’ has no member named ‘object_pp’
/myhomedir/phpurple/purple.c:1408: error: ‘zend_fcall_info_cache’ has no member named ‘object_pp’
I`ve found other people with the same problem:
hxxp://www.mail-archive.com/monetdb-bugs#lists.sourceforge.net/msg05515.html
hxxp://belsky.info/archives/23-Phurple-per-se-PHPurple.html
but nobody gives any information about successful php 5.3 build and the message
PROJECT IS CLOSED if you want
commercial support for php 5.3, let me
know ... )
does not help at all.
does anyone have any idea how to compile it or any clue how to fix the problem ?
P.S. Sorry about the links, some strange StackOverflow limitation
According to phpurple requirements:
Please let me know, if you've successfully compiled on
earlier versions. Actually the extension is being developed
on the php v5.2.6 with the option to be upcomming php v5.3
compatible.
The authors will need to update their source. However, since you have the source you could update it yourself because you noted that the project is CLOSED. You could also fork the code and create your own gitHub project with php 5.3 support.
Good luck.
What you are seeing is PHP's shifty interface (ahem, hold your down votes, I said s h i f t y). By that, I mean function prototypes are subject to change from version to version. Take this meta example:
int foo_call_bar(const char *foobar, size_t len);
And in a later version of something, the function calculates the length dynamically, thus eliminating the second variable in the prototype:
int foo_call_bar(const char *foobar);
Some projects strive to always maintain backwards compatibility to alleviate this headache, which could be accomplished with pre-processor directives that prototype the new implementation with the len variable, but just don't do anything with it. If PHP did that, the code base would succumb to even more madness.
Unfortunately, you'll have to modify phpurple to present the correct arguments to the correct PHP functions, and ensure that they are of the appropriate type. That would be a bit of an undertaking, but probably wouldn't be as difficult as it seems.
The Linux kernel's VFS interface is the same way, and I'm often tasked with porting older experimental file systems to work on modern kernels.
look at that man
http://sourceforge.net/news/?group_id=235197&id=296063
A little late, but here is the latest library that works with PHP 5.3:
The new project page is: http://sourceforge.net/projects/phurple
The blog post: http://belski.net/archives/23-Phurple-per-se-PHPurple.html
I have ran into a problem after I have complied it and added the extension to PHP.ini configuration:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/phurple.so' - /usr/lib/php/modules/phurple.so: undefined symbol: ZVAL_ADDREF in Unknown on line 0
To fix this, change the line containing ZVAL_ADDREF in client.c from
ZVAL_ADDREF(PHURPLE_G(phurple_client_obj));
to
Z_ADDREF_P(PHURPLE_G(phurple_client_obj));
Well, the new URL seems to be a persistent repo with fixes to PHP-5.3 and above. Maybe that should be mentioned, but that won't help with checking it out anyway. For me it worked fine, so I would say it is worth a try.
You can check the new sources shortly posted on https://github.com/weltling/phurple