Hello,
For no reason I can find, Konqueror is displaying my *.php files using mimetype HTML.
Until today, I had it set up in File Associations, if I click on a PHP file, Kate would open and the 'icon' would be my PHP mimetype and HTML files would not only have an HTML mimetype icon, but would open in KWrite.

Image of dir using HTML for PHP
Image of dir using proper PHP mimetype icon
*note: i created the icons in gimp, but am certain they have nothing to do with this issue. again, this just happened and i've been using the icons for a very long time ago.

Al of the sudden, but after Kate locked up and would not 'die' after many attempts to 'Kill' it. (locked while I was in Settings > Configure Kate). I was forced to power down the computer and cold start.

To make a weird thing weirder is that it is Not All Directories. Some sub-directories of the same project display some PHP files using the mimetype icon = php and open in Kate and Some are displaying php files with mimetype icon HTML and opening in KWrite.
All the files with .php extensions Are php, at a minimum contain at least one php include statement. Both the files display HTML or PHP icons.

I've noticed this little issue, when I started creating .mediawiki documents. it seemed Konqueror would interpret them as '.C' code files or 'normal' and Not mediawiki mimetypes. To 'fool' konqueror or really 'the system' I would put at the top of the document, '< ! DocType mediawiki > (NO spaces, obviously)... So, what I'm saying is that it seems 'the system' or konqueror is actually Reading the contents of the file instead of the file Extension...
What do you think?

Any Ideas Please?
Reed.

-- edit --
one more thing. on my web servers, all the mimetypes seem to be right, but i also have x-app set in file associations that might be different from the 'text' setting.

KDE applications, including Konqueror, KWrite and Kate use a system known as mimetypes to determine the icon to show and the application(s) which can handle the files.

To determine the mimetype, they use "magic data" and file extensions, with magic bits being given precedence I believe. To determine if the magic data matches, the file is read as much as is necessary. When you are browsing a remote system this method would be too inefficient, so it relies purely on file extensions, or if the protocol supports it, the mimetype provided by the server.

This only explains the web server and Mediawiki file issues though.

As for the HTML/PHP issue - could you try reproducing this under a new account? Also, try running "kbuildsycoca4 --noincremental" as your normal user - this should help regenerate any caches which might be causing this issue.

bcooksley wrote:...
To determine the mimetype, they use "magic data" and file extensions, with magic bits ...

this is what I've always been afraid of with 'Akonadi', 'Strigi' and 'Nepomuk' semantic desktop indexing... they will remember what they want and not what I want and like windows was in the late 1990's early 2000, remember wrong and undoing the index was hell.

This only explains the web server and Mediawiki file issues though.

As for the HTML/PHP issue - could you try reproducing this under a new account? Also, try running "kbuildsycoca4 --noincremental" as your normal user - this should help regenerate any caches which might be causing this issue.

bcooksley, is the 'kbuildsycoca4' command something that is going to take a very long time and high CPU, that should be done when I Don't need to work on other things?
What is going to change on my system... I'm Very fussy as you might gather.. Will I notice adverse effects?

Thank YOU for Your help,
Reed.

The system of mimetype determination has been in place for a long time, and was also used in the KDE 3 series if I recall correctly. Examining the content of files is significantly more reliable in most circumstances at determining what type of file it is.

The kbuildsycoca4 command I gave should take less than 30 seconds to complete, with the exact time depending on your hardware. It shouldn't take any more than 1 minute at worst. All it does is rebuild a central cache which is used to allow KDE to lookup associations, applications, etc. in a rapid fashion.

Thank you again.

I ran the kbuild command and it took less than 30 secs..
lots of stuff echoed to the console. I'll look through it before i close console..
example of output:

Code: Select all

kbuildsycoca4(3688) KBuildServiceFactory::createEntry: Invalid Service :  "/home/landis/.local/share/applications/tidy.desktop"
kbuildsycoca4(3688) KConfigGroup::readXdgListEntry: List entry MimeType in "/home/landis/.local/share/applications/librecad-3.desktop" is not compliant with XDG standard (missing trailing semicolon).
kbuildsycoca4(3688)/kdecore (services) KServicePrivate::init: The desktop entry file  "/home/landis/.local/share/applications/tidy-2.desktop"  has Type= "Application"  but no Exec line

I'll see if it helps cleanup some of the mixed icon to document types in some directories...

Thanks,
Reed.

Usually the output of kbuildsycoca4 can be safely ignored - they're merely warnings about files which aren't fully compliant with the specification.

Thank You.
the file type associations have been more often correct since i started this post...
could be the flush command you gave me 'kbuildsycoca4 --noincremental'

again, thanks
Reed.

Not a problem - if the issue is now solved, please mark the appropriate post as such using the "Accept this answer" button.