• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Parse error: syntax error, unexpected '$this' (T_VARIABLE)

nisamudeen97

Regular Pleskian
I was experiencing strange error "Parse error: syntax error, unexpected '$this' (T_VARIABLE) in /httpdocs/app/code/core/Mage/Catalog/Model/Abstract.php on line 116 with my php codes which is properly executed in my local machine. This happens when I upload files via FTP.

I have done a detailed investigation and I could see a random string "^Mt" appears in the mentioned line which has caused the error. I have manually removed this string and the problem is solved. I would like to know how this happens?

I have tested the same with different computers and I could see the same issue. Is the "^Mt" denotes some escape character?

I have four servers having plesk. The issue is only with one particular server. I have tried the same on others meanwhile it is not having the issue. I strongly feel the issue is with ftp service with plesk. Is it some kind of encoding issue?
 
@nisamudeen97

The ^M is a carriage return (used in DOS/Windows) and equal to \r (used in Linux/Bash).

Normally, you should try to prevent the usage thereof: it is to be preferred to use \n (new line in Linux/Bash) or, even better, use it NOT ALL (use vim end press enter for a new line).

Hope the above helps and explains a bit.

Regards
 
Hi,

The reported issue is noted with only one server. I have uploaded the same codes to another server meanwhile the issue doesn't exists there.
 
@nisamudeen97

I know that the issue occurs without any consistent persistence and I presume that it is package related, with the difference between servers explained by differences in package versions.

You can have a look, but in general, I would not really be worried, if you were already able to solve the problem in the one php file.

Regards....
 
Hi,

I have hosted more than 10 domains in the server and all the domains are having the issues. I wish to have permanent solution for this.
 
@nisamudeen97

You stated that the error is present on multiple domains and that

unexpected '$this' (T_VARIABLE) in /httpdocs/app/code/core/Mage/Catalog

which facts together imply that there is some bad code (resulting in a php syntax error) in a specific application.

You can only do two things: update the application and/or, if updating does not help, submit a ticket or bug report to the application supplier.

It is not a Plesk issue.

Regards....
 
I had a similar issue in the past days where ASCII files gets corrupted during upload - Could it be related to this ?

https://forums.proftpd.org/smf/index.php/topic,11956.0.html

It looks like the 1.3.6rc2 Proftpd (the version shipped in psa-proftpd package from AtomicRepo)
is buggy and it is causing ASCII file corruption during FTP upload due to a problem with Windows carriage returns handling,
so please check your FTP server version (proftpd -v)

There are two workarounds at the moment :
- Downgrade to latest stable version (1.3.5e) (in CentOS/RHEL -> # yum downgrade psa-proftpd )
- Replace all CRLF with LF before uploading the file.
 
Same here. This should be fixed asap. I already have a few (just a few luckily) customers who complained about this.
Told them it was their buggy script, though it seems ProFTP is the culprit here. I don't understand why I received this update for our servers though from Plesk...
 
It looks like the 1.3.6rc2 Proftpd (the version shipped in psa-proftpd package from AtomicRepo)
is buggy
Just use psa-proftpd from Plesk repository. For example, on my test Plesk 12.5 server I see:

# rpm -qi psa-proftpd
Name : psa-proftpd Relocations: (not relocatable)
Version : 1.3.5a Vendor: Plesk
 
FYI - As today - The actual stable version I have on my Centos 7 "standard" boxes is 1.3.5e
(no bug on that).

However I have some Centos 6 boxes with Atomicorp repo
(that is listed as officially supported by Plesk) in order to stay updated with PHP / MySql package.
That boxes "yum-updated" the psa-proftpd package to version 1.3.6rc2 (the buggy one)
 
@gennolo and @HHawk,

A PHP syntax error is unrelated to proftpd or the package version thereof.

In short, there is no reason to link the PHP syntax error to proftpd transfer modes, certainly when taking into account that the corresponding proftpd bugs 4236/4237 are mute (read: not bugs at all, simply stated) AND, more important, that the proftpd bug 4151 is unrelated to PHP syntax errors and that this bug has been resolved in proftpd version 1.3.6rc2 (hence implying that any error of the "bug 4151" kind should not occur in version 1.3.6rc2, which was at least installed for some time).

To be honest, do not mix up issues and just use the default package provided with Plesk, as @IgorG already stated.

Regards....
 
Hi @trialotto

I have already updated the issue clearly, I have 4 plesk servers and the reported issue is only with latest plesk server. I have uploaded the same files to other plesk server and tested where the issue does not exist.

As the issue is unresolved, I have canceled the license for new plesk server.
 
@nisamudeen97

The freedom of choice is fully yours, but I really have to emphasize the following.

First, note that I am speaking on a personal title, I am not speaking on behalf of Plesk Team (read: Product Experts are not part of Plesk or Plesk Team)

Second, if at least ONE of the Plesk Panel users is not experiencing the same issues (that you encountered), then those issues are not related to Plesk Panel or it´s components.

Note that MOST of the Plesk Panel users do not have these particular issues.

Also note that I (and probably other parties) cannot reproduce this particular (alleged) issue (and I tried really hard).

Third, if the issue is related to a somewhat clumsy bug in proftpd, then you will experience the consequences of this bug in specific proftpd versions, no matter what panel you will use.

Note that a cPanel (or any other hosting panel) with the same buggy proftpd version will give you the same or similar problems.

Also note that the specific clumsy bug in proftpd is the consequence of actions taken by the "proftpd team", the bug is in no way related to actions taken by the Plesk Team.

Fourth, if you use external repositories, instead of the official Plesk repository, you can end up with a component that is not shipped with Plesk.

Note that the usage of external repo´s is not recommended (unless one knows what one is doing), since it could result in incompatibility issues with (other) Plesk components.


In short, I can understand why you cancel a license, but you should take a tip from me: it has nothing to do with Plesk or Plesk Team, so it is not wise or convenient to take a lot of actions and then essentially choose the wrong option (i.e. destroying a Plesk server), without resolving the actual issue (that takes less time: install default psa-proftpd version 1.3.5a).

Naturally, if any actual bug in the psa-proftpd package is identified, the bug will be fixed (and destruction of the Plesk server implies that you will not benefit from potential bug fixes).

In conclusion, I am a little bit flabbergasted about the choices you have made.

Regards.....
 
For the records :
I'm doing some tests with proftpd team to isolate the problem.
I built up a Centos 6 box from the scratch and installed 1.3.6rc2 from the official source : no more ASCII corruption problems.

So the "buggy" package appears to be the only in the psa-proftpd shipped in the Atomic repo.

I suggest to follow the advice of IgorG and stay with 1.3.5e package from official Plesk repo.
 
@gennolo

Nice to hear that you confirm what I already stated implicitly and/or what proftpd team already stated explicitly.

It can do no harm to have some clarity about this particular issue, certainly when taking into account the erroneous conclusions that have been drawn before.

Regards....
 
How do you change from Atomic ProFTPD rpm release to the original Plesk rpm release?
I only want to change it for ProFTPD though, nothing else.

Thank you.
 
@HHawk,

It should be possible to (only) exclude proftpd from the Atomic repolist, but I am not sure whether it can be recommended.

However, let´s try, but first give me an indication of your OS and the exact (!) package name of proftpd (as installed right now).

Normally, it would be quite easy, but with your requirement, one has to remove the Atomic proftpd package, install the Plesk proftpd package with all proper dependencies from the regular repolist AND make sure that all future updates are taken from the normal repolist (not the Atomic one).

You can imagine that it already is challenging, but it can also be dangerous: future updates can cause dependency related issues with packges.

In short, we can try, but there are some pitfalls (but note that it is only proftpd, so any dependency related issues would be minor).

Regards

PS While typing, I saw the suggestion of @gennolo entering the topic thread. You should be aware that

- a downgrade (as described by @gennolo) is an option, but any future update will result in an Atomic based proftpd package, (and)
- locking packages is not a good idea at all: proftpd will not be updated at all (unless you release the lock and update manually)

so that suggestions is only a temporary work-around, not a permanent solution.
 
Thank you gennolo and trialotto for your (detailed) answers. Highly appreciated.

Well as soon as I downgrade the ProFTPD version (on my own server) it will be updated once again the next day.
The installed version is: ProFTPD Version 1.3.6rc2 (psa-proftpd). If I am not mistaken, it's 1.3.6-10.el6.art.
Further details:
Version: 1.3.6rc2 (devel)
Platform: LINUX [Linux 2.6.32-042stab113.21 x86_64]
Built: Mon Mar 21 2016 15:40:44 EDT


After doing the downgrade process it will be back at version: ProFTPD Version 1.3.5a (psa-proftpd)
This is version: it's 1.3.6-9.el6.art.
Further details:
Version: 1.3.5a (maint)
Platform: LINUX [Linux 2.6.32-042stab113.21 x86_64]
Built: Wed Sep 23 2015 09:46:01 EDT

Running CentOS 6 on my own server.

As I mentioned above I run 'yum downgrade psa-proftpd' so version 1.35a is running, but the next day it's back to 1.3.6rc2. Sigh.
 
@HHawk,

It is not really a surprise that the downgrade process results in the "same" rc2 version the next day, I have predicted that.

A huge part of the problem seems to be the package name itself: they are identical and without that, a solution would be easy.

At this moment, there are two potential solutions, a more elaborate one and a simple one.

Let´s start with the simple one, involving the command line autoinstaller for plesk.

I am not sure whether it works, but let´s just try it:

1) run the command: yum remove psa-proftpd

This will remove the package, as provided by the Atomic repo. It is a bit tricky, since dependent packages can also be removed. Not a problem though, in this case.

2) run the command: /usr/local/psa/admin/sbin/autoinstaller and follow the lists, install FTP server.

This will install the package, as provided by Plesk. Note that you can also check for any problems: if the autoinstaller has a cross in front of the FTP server option, then your issues with the proftpd server originate from something completely different or the command from point 1 has not been executed properly.


If I am not mistaken, the server will not automatically update to the rc2 version the next day: it will use the psa-proftpd package as provided with Plesk.

Just let me know whether this works, otherwise I will be happy to investigate the issue in order to find a permanent solution (just give me some time, since time for me is scarce).

Regards.....
 
Back
Top