Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170
Error messages - Page 2 - Macrotone Forum

Unknown Error 8192: KunenaControllerApplicationDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in libraries/kunena/controller/application/display.php on line 21


Unknown Error 8192: ComponentKunenaControllerWidgetAnnouncementDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/widget/announcement/display.php on line 18


Unknown Error 8192: ComponentKunenaControllerTopicItemDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/display.php on line 25


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/forum/category/category.php on line 415


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/route/route.php on line 437


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/bbcode/bbcode.php on line 107

Error messages


Unknown Error 8192: ComponentKunenaControllerTopicItemActionsDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/actions/display.php on line 23


Unknown Error 8192: ComponentKunenaControllerTopicPollDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/poll/display.php on line 21


Unknown Error 8192: ComponentKunenaControllerTopicItemMessageDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/message/display.php on line 23

11 years 7 months ago #7 by freddiesfather
Replied by freddiesfather on topic Re: Error messages
Hi Geoff,

In the first scenario when I received the errors the unregistered user received an "opened" email as well as the assignee.

In the second scenario after amending the php file the unregistered user never received an "opened" email but the assignee did.

When I then registered the user in the second scenario the joomla email activation link was sent successfully.

Regards

Wayne

Unknown Error 8192: ComponentKunenaControllerMessageItemActionsDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/message/item/actions/display.php on line 25

Please Log in or Create an account to join the conversation.

11 years 7 months ago #8 by geoffc
Replied by geoffc on topic Re: Error messages
I am having great difficulty in replicating this problem.

In every situation I get emails sent to the user, assignee and administrator when an issue is opened, updated or closed.

Whether the issue is created and/or updated on the front end the emails get generated, which is not totally surprising since the email code is located in the back end helper routine which is called from the front and the back end.

I shall keep looking but I may end up having to ask you to insert some debug code to try and pin it down further.

In file administrator/helpers/issuetracker.php (Site: administrator/components/com_issuetracker/helpers/issuetracker.php)

After line 988 (the commented out print line)
Add: $app->enqueueMessage('In send email '.$what.' '.$to);

Then if you could try your tests again.
This will create a message for the user notification and for the assignee notification. The routine 'send_email' is used for user and assignee messages.
i.e:

In send email user_update This email address is being protected from spambots. You need JavaScript enabled to view it.
Issue No: ZX2SI6TGR6
Issue Saved!

Where the message type is the third word and the address is the last word on the line. This will tell me whether the request to send the message is being made or not and might help to pin the problem down further.

Edited by geoffc - 18.09.2012 18:41

Regards
Geoff

Please Log in or Create an account to join the conversation.

11 years 7 months ago #9 by freddiesfather
Replied by freddiesfather on topic Re: Error messages
Hi Geoff,

I added the line of script as you advised. I updated the issue on the front end logged in as admin (for this test there is only one admin who is also assignee) and the email sent to is the admins (assignee). Again no email was sent to the user, however I have noticed that the issue itself in the backend shows the identified by as being the admin! However as I previously explained in the second scenario the initially unregistered user created the issue! So I am a little confused?

Regards

Wayne

Please Log in or Create an account to join the conversation.

11 years 7 months ago #10 by geoffc
Replied by geoffc on topic Re: Error messages
If the identified_by has been changed to the admin then that would explain why no user email was sent on the update. This is possibly not an email problem at all. Hmmm. Now to find out why the identified by was changed.

---
Have found a possible scenario where:
1) Guest user creates an issue. ( No non-registered entry in it_people created. - not configured.)
2) Email notification was requested and sent.
3) Admin user edits issue in front end. identified_by changed to admin. No user update mail sent.

Will supply fix shortly once I have tested it.

This does not impact guest users creating an issue and the creation of un-registered entries in it_people is configured.

Edited by geoffc - 19.09.2012 10:49

Seems that the possible scenario doesn't occur. However in investigating I found a few other problems which I have fixed which impacted whether the issue was editable on the front end.

Rather than send you the fixes I have created a new folder under the Issue Tracker download area called 'Development Releases' I will put up a new zip file which you can access if you login into the site and download it. That is probably a much better solution to sending fixes for you to apply.

Edited by geoffc - 19.09.2012 18:21

In my tests I have been unable to find a case of the identified_by being changed to the admin user once they have edited the user raised issue. If you are still seeing the problem I will investigate further. Let me know how you get on. Thank you for your patience and perserverance with this.

Edited by geoffc - 19.09.2012 18:52

Regards
Geoff

Please Log in or Create an account to join the conversation.

11 years 7 months ago #11 by freddiesfather
Replied by freddiesfather on topic Re: Error messages
Thank you Geoff.

I will give that update a try. Just out of interest is that an install over the top?

The reason I ask is when I did that with 1.2.1 upgraded to 1.2.2. straight over the top it went a little haywire and in the back end - Components - Issue Tracker - People existing users notify and type etc were not populated with the brown circle or tick and clicking where the image should be did not change the status. I could only remedy this by wiping the server and restoring a backup that is just Joomla installed and then installed 1.2.2. Obviously in my test area this is not a problem at all but in a live area I would not have the facility to do this.

Regards

Wayne

Please Log in or Create an account to join the conversation.

11 years 7 months ago #12 by geoffc
Replied by geoffc on topic Re: Error messages
That is strange. I have always just installed on top of the existing installation. I have never seen the behaviour you describe. One of the tests I always perform involves upgarding an existing installation, and I have always upgraded my live site.

Perhaps its a platform effect. I run on Unix base systems for all my test and my live systems.

If you can provide details of your test system configuration I can try and replicate the problem. Never having had the problem raised before I was unaware there was a problem.

Anyway to answer the question, it should just install on top of the existing installation. There are no database changes and only a few php files have been changed.
----

Have looked at the 1.2.1 to 1.2.2 upgrade and there is nothing in there that changed that I can think of that would impact the people display. I am wondering it is some form of cache problem. It might be worthwhile clearing the Joomla cache (if enabled) and your browser cache if you see the problem again. It shouldn't be neccessary to do a fresh install.

Edited by geoffc - 20.09.2012 11:38

Regards
Geoff

Please Log in or Create an account to join the conversation.

Time to create page: 0.292 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries