Yea that logo thing is weird. Check all logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.) for any related errors.
Cheers.
Migrating from1.12.2 to 1.18.1 issues
Okey dokey, looks like the image issue was self inflicted. I reverted all my php changes and now it's working correctly. I'll have to go through my code and see what/where it breaking.
Any thoughts on why the _user_account table didn't update the backend correctly with the update?
That’s exactly why I asked if you had any mods to the code/database.
Most likely a glitch during that upgrade. It can happen.
Cheers.
5 days later
I did get everything working. Turned out I had a typo in how I added a comment to a php file and that was breaking everything 
Still have the issue of the _user_account table not having the backend column updated by the update script.
Found one more thing. When viewing a ticket on the agent side that was brought over with the db import the 'Issue Description' field seems to be stipping off the "<br />" tags that are saved in the db.
Here is what the value is in the db
Hi Dave, <br />Please replicate the following tables from dataLink.<br /><br />Server: srv90037<br />Database: lccIRDataLinkDataWarehouse<br /><br />WAREHOUSE_FINAID.FA_AWARD<br />WAREHOUSE_FINAID.FA_AWARD_SNAPSHOT<br />WAREHOUSE_FINAID.FA_STUDENT<br />WAREHOUSE_FINAID.FA_STUDENT_AWARD<br />WAREHOUSE_FINAID.FA_STUDENT_AWARD_SNAPSHOT<br />WAREHOUSE_FINAID.FA_STUDENT_AWD_CANCELED<br />WAREHOUSE_FINAID.FA_STUDENT_NEED<br /><br /><br />I just created a target file using the lccFileRowsTurnOnOff tool. The tables that need to be updated were all found in the tool's checkboxes.<br /><br />Thanks! <br />
And here is how it's being displayed in the browser
Hi Dave, Please replicate the following tables from dataLink.Server: srv90037Database: lccIRDataLinkDataWarehouseWAREHOUSE_FINAID.FA_AWARDWAREHOUSE_FINAID.FA_AWARD_SNAPSHOTWAREHOUSE_FINAID.FA_STUDENTWAREHOUSE_FINAID.FA_STUDENT_AWARDWAREHOUSE_FINAID.FA_STUDENT_AWARD_SNAPSHOTWAREHOUSE_FINAID.FA_STUDENT_AWD_CANCELEDWAREHOUSE_FINAID.FA_STUDENT_NEEDI just created a target file using the lccFileRowsTurnOnOff tool. The tables that need to be updated were all found in the tool's checkboxes.Thanks!
Interestingly when I click to edit the ticket (as an agent), then everything displays correctly.
Sure no problem.
Here is a screenshot from the 1.12.2 system
Here is a screenshot from the 1.18.1 system (/scp/tickets.php?id=24766)
Here is a screenshot from the edit ticket page on the 1.18.1 system (/scp/tickets.php?id=24766&a=edit)
- Edited
I figured that’s what you were talking about but wanted to make sure. That is the expected functionality. The display with HTML was causing issues so we started displaying it in plain-text only. If you want to see the full rendered HTML content simply click on it and it’ll bring up the preview window.
The only problem would be if the Agent didn’t have edit permissions for the Ticket or if the Field is not editable to Agents.
Cheers.
That is actually a huge problem for us. Seems like turning off/on the display of HTML should be up to us. Do you have any recommendations for how to fix this? I cannot go live with the upgrade until that is fixed (it's that big of an issue).
You’d have to customize the code for that. There is no option for this; won’t be an option until after v2.0.
Cheers.
OK, thank you. Couple more thoughts and questions about this.
When did this get changed? From your stand point, would there be any issues with grabbing the code from the 1.12.1 system and using it in the 1.18.1? I mean just the part for displaying this with HTML.
I'm also a bit baffled as to why we have a wysiwyg type box on the user side for them to type in all kinds of fancy HTML kinda stuff and then completely strip it out when the agent views the ticket. Just trying to understand the bigger picture as to why this change was made.
BTW, huge thank you for all your time in the forum here and all your work on this!
A while ago; you’d have to go look at the commit history for exact date.
No, as there is more to it than that. Textarea fields have their own AJAX endpoint and all that. So a bit will need to be reworked.
You can still see the full rendered content you just need to have edit permissions so you can simply click the content and get a full preview window.
The issue was we truncate textarea field content in the header (as it could get way too long) and if you truncate HTML it’s incomplete and breaks the whole page as it too is HTML. We also have inline edit now so you don’t edit the full ticket anymore for simple field updates. Each field value is clickable so you can update just that field. So with that being the new norm it made sense to display partial plain-text first then you click it to see the full rendered content.
Cheers.
Thank you for all that help. Given I'm on a dev server right now I was able to test out and idea that seems to be working and wanted to let you know what I did.
In the file include/staff/ticket-view.inc.php I found where the Laravel function Format::striptags() is being used to strip out all the HTML. Since this function does not have any built-in control options I switched over to using the PHP funtion strip_tags(). Here is the snippet of what I did that is working for me.
foreach ($displayed as $a) {
$id = $a->getLocal('id');
$label = $a->getLocal('label');
$field = $a->getField();
$config = $field->getConfiguration();
$allowedTags = '<p>,<br>';
$html = isset($config['html']) ? $config['html'] : false;
/* $v = $html ? Format::striptags($a->display()) : $a->display(); */
$v = $html ? strip_tags($a->display(), $allowedTags) : $a->display();
$class = (Format::striptags($v)) ? '' : 'class="faded"';
$clean = (strip_tags($v, $allowedTags))
? ($html ? strip_tags($v, $allowedTags) : $v)
: '—' . __('Empty') . '—';
/* $clean = (Format::striptags($v))
? ($html ? Format::striptags($v) : $v)
: '—' . __('Empty') . '—'; */That’s not a Laravel function; it’s a custom osTicket function 
We had to define everything ourselves back then; we didn’t use any frameworks.
Cheers.
- Best Answerset by KevinTheJedi
I did find where that is being defined. I removed my previous edits made changes appropriate to where the static function is built.
Here is what I have done. I added a variable to the include/staff/ticket-view.inc.php for $allowedTags and then added this variable to the places where Format::striptags is called. I then added the strip_tags function inside the custom static function. This would allow the flexibility of defining the $allowedTags per item, per page. Snippets are below
include/staff/ticket-view.inc.php
$allowedTags = '<p>,<br>';
$v = $html ? Format::striptags($a->display(), $allowedTags) : $a->display();
$clean = (Format::striptags($v, $allowedTags))
? ($html ? Format::striptags($v, $allowedTags) : $v)
: '—' . __('Empty') . '—';include/class.format.php
static function striptags($var, $excludedTags=null, $decode=true) {
if(is_array($var))
return array_map(array('Format','striptags'), $var, array_fill(0, count($var), $decode));
return strip_tags($decode?Format::htmldecode($var):$var, $excludedTags);
}KevinTheJedi locked the discussion.