Akeeba Ticket System

Wednesday, 27 November 2019 12:22 CST

weeblr

Hi

I recently updated one of our site from ATS 2.4.x to 3.0.4. An issue has appeared with reply by email (which was working fine for the last feaw years). I spent a fair bit of time trying to understand this and It seems there's a problem linked to PHP setup and/or ATS:

Symptoms: all the fetching is fine, the email messages are fetched and parsed normally but replies from users are not saved as posts in existing ticket. I do not allow opening tickets by email. The user receives a message saying "New post creation failed":
"Oops! Something went wrong trying to create your post. It's probably not your fault. Please visit our site and try posting your ticket or ticket reply there."

Tracking down: There's a PHP notice in my logs for each attempt:

PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /var/www/weeblr.com/www/public/libraries/joomla/session/handler/native.php on line 235

I also get this one, but I don't think it's related:

PHP Notice:  Trying to get property 'created_by' of non-object in /var/www/weeblr.com/www/public/administrator/components/com_ats/Helper/Permissions.php on line 369

What I found: it appears that having any outputduring the CLI operation causes this warning to happen. I assume not being able to create/resume a session breaks Fof or similar, which then cannot save the post.

Things attempted In cli/ats-mail-fetch.php, I tried to change:

$model->checkEmail(true);

to

$model->checkEmail(false);

But despite setting $cliFeedback to true, the CLI itself actually has a lot of output, including

Akeeba Ticket System -- Fetch email for the Reply By Email feature

SolutionEventually I commented out all instances of $this->out(), in addition to setting $cliFeedback to false. The cli then produces absolutely no output and the replies sent by email are normally posted.

Dose that ring any bell?

Yannick

Edited by weeblr on 2019-11-27 12:23 CST

Wednesday, 27 November 2019 12:57 CST

weeblr

Hi again,

Side note, PHP version is 7.2.24, not 7.2.4.

Best regards

Thursday, 28 November 2019 01:04 CST

nicholas

We are already aware of the issue. The root cause is Joomla. Next week's update will solve it.

When filing any ticket we need to perform some checks against the current Joomla user as part of the guest ticket feature. The only way to do that is to eventually go through Factory::getUser(). This tries to find the user object in the session which, at this point, is uninitialized.

Unfortunately, both of Joomla 3's session handlers use PHP sessions, even under CLI. However, you cannot initialize a cookie-based session in CLI because, um, it's CLI! PHP throws the warning and returns false. Joomla believes it cannot start the session and crashes out.

The solution was convoluted and involved me writing a custom CLI session handler for Joomla 3. For Joomla 4 I had to manipulate our container to go through Joomla's session.cli service under CLI. It was a "fun" day of troubleshooting, for "hitting my head on the desk and shouting profanities to Joomla" values of "fun".

Eventually I moved all of that code in FOF because it affects all of our CLI scripts. Next week I'll publish the new FOF version and the new versions of ATS, Admin Tools and Akeeba Backup which take advantage of its new master CLI script feature that works around all the Joomla craziness.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 28 November 2019 01:47 CST

weeblr

Hi

When filing any ticket we need to perform some checks against the current Joomla user as part of the guest ticket feature. The only way to do that is to eventually go through Factory::getUser().

Can't you read straight from DB? In the CLI context, there's no session indeed so it's likely only the "hard" user data you're looking for, username, email address,etc

Anyway moving away from Joomla API for this kind of usage sounds like a sane thing to do!

I'll wait til next update with my custom changes in as it's currently working.

Cheers

Thursday, 28 November 2019 07:09 CST

nicholas

I think I didn't explain this very well :) I need to check if there is a currently logged in user. Joomla logs in a user by writing the User object in the session. Therefore, no matter what I do, I end up going through the session.

My solution for Joomla 3 is to write a custom class implementing JSessionHandlerInterface to "fake" the CLI session. This approach is inspired by Joomla 4's CLI Session service which was, in turn, inspired by the "fake" session I was using internally in FOF 3. That was a weird turn of events with my idea coming full circle twice.

The solution for Joomla 4 is to make my base CLI application extend CliApplication so I can register it with Joomla\Factory and provide a getSession() method which returns the 'session.cli' service from Joomla 4 DI Container. This was actually more convoluted than writing a custom handler since the CliApplication constructors are drastically different in J3 and J4 which meant that I needed to do a wacky version detection before I can load Joomla and create a base CLI application class which necessarily extends from a different base class based on Joomla version.

In short, I couldn't circumvent Joomla's API. I had to do some weird calisthenics.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 28 November 2019 07:24 CST

weeblr

Hi

I need to check if there is a currently logged in user.

From CLI scripts? I might be missing something here: I don't see how there can be such thing as an already logged-in user in the context of CLI scripts. But maybe this is because you share some code (checkEmail model) between CLI and web operations?

Anyway, looking forward for update to fix it.

Best regards

Thursday, 28 November 2019 08:26 CST

nicholas

The check has to be done in the Model.

While we could add a check "is this CLI" it didn't really solve the problem that Joomla\Factory will crash and burn if anything asks for the current user.

Since our ATS CLI script need to load plugins (e.g. to send emails) we have no guarantee that a third party plugin won't trigger the same issue. So instead of addressing the code in the Model today (and possibly missing something else now or in the future) I decided to address the root cause.

For what it's worth, developers should NOT have to concern themselves about CLI vs web in the Model code. The session as a means of fast, temporary, in-memory storage that persists beyond the lifecycle of the object should be a given. Otherwise we end up with God objects. I might appear insane but there is method to my madness :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 28 December 2019 17:17 CST

System Task

system

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Edited by on 2019-12-28 17:17 CST

Support