Forum Subject: HTML tags stripped in 1.3.8sr2
Posted on: 10/28/03 07:09pm
By: tsavage
Upgraded to 1.3.8-1sr2 and now I can't save HTML formatting. Any idea what's up?
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/29/03 02:01am
By: Dirk
Did you add the new config variables in config.php?
bye, Dirk
bye, Dirk
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/29/03 11:11pm
By: tsavage
Yep, I got rid of the allowablehtml and adminhtml in config.php, replaced by the user_html/admin_html changes (tried to paste the snippet in here, but the forum wouldn't let me).
HTML is stripped from stories and comments, but not Static Pages...
HTML is stripped from stories and comments, but not Static Pages...
I'd like to add that target=whatever doesn't show up!
Posted on: 10/30/03 06:18am
By: Anonymous (Guest)
HTML still works for me, but I can't open in new window!
What gives?
What gives?
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/30/03 06:20am
By: Anonymous (Guests)
Hmm, I wrote it in the subject, but I don't see subjects here,
so here's what I meant:
The new version won't let me used target=whatever
It is also retroactive, so every piece I've ever written now
doesn't have a target, and it opens on my own blog!
What gives?
so here's what I meant:
The new version won't let me used target=whatever
It is also retroactive, so every piece I've ever written now
doesn't have a target, and it opens on my own blog!
What gives?
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/30/03 06:29am
By: Anonymous (Guest (again))
Well, I've added "target" to allowedhtml in config.php (into
the <a's already mentioned "href" and "title"
and it works!
But am I now expected to go through every article ever
written and change it manually?!
Why did you remove it/stopping making it automatically in
the first place?
the <a's already mentioned "href" and "title"
and it works!But am I now expected to go through every article ever
written and change it manually?!
Why did you remove it/stopping making it automatically in
the first place?
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/30/03 06:29am
By: Dirk
Simple: 'target' is not an allowed attribute by default - you will need to add it (to the 'a' tag).
Or better yet - don't do it. Opening new windows is annoying (search for my previous rants on this topic ...).
bye, Dirk
Or better yet - don't do it. Opening new windows is annoying (search for my previous rants on this topic ...).
bye, Dirk
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/30/03 06:37am
By: Anonymous (Guest (sorry, but...))
Well, I've just found out that "target" only dissapeared for
those articles that were saved AFTER the new version.
I just never noticed it until today.
So there's not much to fix.
But still, please don't do it again without warning...
those articles that were saved AFTER the new version.
I just never noticed it until today.
So there's not much to fix.
But still, please don't do it again without warning...
Re:HTML tags strippted in 1.3.8sr2
Posted on: 10/30/03 10:48am
By: tsavage
Well, that was interesting, but kinda sidetracked on my original question...
Any thoughts on the HTML stripping? I've rechecked all the changes, putting in the kse stuff. I did the upgrade using a diffs program on config.php and lib-common.php, carefully, manually adding and commenting out/deleting.
Went from 1.3.8-1 to -1sr1 to -1sr2 (just uploaded users.php) in one session. But I guess the problem actually happened in 1.3.8-1sr1, since that's where all the new stuff came in.
As it is, I can't edit earlier articles, cause the formatting gets stripped out when I resave. Should I roll-back for now?
Any thoughts on the HTML stripping? I've rechecked all the changes, putting in the kse stuff. I did the upgrade using a diffs program on config.php and lib-common.php, carefully, manually adding and commenting out/deleting.
Went from 1.3.8-1 to -1sr1 to -1sr2 (just uploaded users.php) in one session. But I guess the problem actually happened in 1.3.8-1sr1, since that's where all the new stuff came in.
As it is, I can't edit earlier articles, cause the formatting gets stripped out when I resave. Should I roll-back for now?
Re:HTML tags stripped in 1.3.8sr2
Posted on: 10/30/03 11:06am
By: Turias
Well, other than doublecheck your formatting of the HTML tables in config.cfg as they can be somewhat confusing, I would download the 1.3.8-1sr1 again and make sure that kses.class.php, lib-sessions.php, and mysql.class.php are all in the correct locations. Also, I would diff the 1.3.8-1sr1 lib-common.php and config.php with your own again. Maybe you accidentally missed something?
Re:HTML tags stripped in 1.3.8sr2
Posted on: 10/30/03 02:03pm
By: tsavage
OK, since this seems to be my own private problem that's afflicting no one else, I guess it's something to do with my installation. I'll go over it all again, again!
Thanks!!!
Thanks!!!
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 10:13am
By: Anonymous (Merlisk)
I'm having the same problem. All of my HTML tags are stripped from new stories.
My "Allowable HTML Tags:" shows blank, even though config.php has a plethora of them.
I'd love some help.
My "Allowable HTML Tags:" shows blank, even though config.php has a plethora of them.
I'd love some help.
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 10:55am
By: Merlisk
Well, I'm still working on the html stripping issue.
One thing that I don't understand is that when I recursively grep the geeklog directories and my equivalent of the public_html directory for "$_CONF['user_html']", I only find it in config.php.
I don't see any other .php file that uses it.
Now, after looking at story.php, I notice that COM_allowedHTML is used, but I don't see it defined anywhere.
Of course, I'm not a PHP programmer, so I could be totally off base here.
My problem still exists. Thanks for any help you can point my way.
Regards.
One thing that I don't understand is that when I recursively grep the geeklog directories and my equivalent of the public_html directory for "$_CONF['user_html']", I only find it in config.php.
I don't see any other .php file that uses it.
Now, after looking at story.php, I notice that COM_allowedHTML is used, but I don't see it defined anywhere.
Of course, I'm not a PHP programmer, so I could be totally off base here.
My problem still exists. Thanks for any help you can point my way.
Regards.
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 10:58am
By: Dirk
COM_allowedHTML() is a function in lib-common.php
You didn't say which version you're on and whether it's an upgrade or a fresh install. If it's an upgrade, you may have forgotten to upload a few of the new/changed files ...
bye, Dirk
You didn't say which version you're on and whether it's an upgrade or a fresh install. If it's an upgrade, you may have forgotten to upload a few of the new/changed files ...
bye, Dirk
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 11:03am
By: tsavage
Dunno if this'll help much, but I solved my problem in this thread, and many others, by doublechecking mods I'd made to the core code. GL is generally really great for tweaking, 'specially if you don't "know" PHP, but as soon as you get outside the config.php file, and the templates, you really gotta pay attention to what you leave in, change, remove... Quite often, little mistakes don't break the program, they just have odd effects. And, though the templates are pretty good, there's still some stuff that you have to go into the code to change (like, for example, the default stuff on the top menu bar, "polls", "links", "advance search", etc).
Though I often don't bother, a good common sense 3-step approach to safely making any changes is, starting from an installation that's working fine:
1) make a BACKUP COPY of each file you're gonna modify, BEFORE touching it;
2) keep track of what you did by COMMENTING IN THE CODE where the change is made, y'know:
and also, especially if you're making lots of mods, keeping a Changelog, a list of what you did where, basically, copy your MYCHANGE notes with filename and location (eg: line number).
By commenting with a standard unique tag like MYCHANGE, you can use any text "find in file" routine (they're in lots of text editors and standalone utilities) and find all of your changes in all program files in a few seconds. (This is good for replicating your mods after upgrading GL.)
3) (Especially with lots of changes) check your progress by running GL after each mod to make sure it STILL WORKS, to catch errors early.
Doing the above actually becomes fairly automatic and doesn't take much time at all. With that stuff, you can always step back from an error to a working version by undoing your recent changes (and in extremes, roll back to the backup files that definitely worked). And it's real easy to zone in on where the problem may be when hitting a forum like this!
Also, this system definitely comes in handy when installing integrations, like Gallery, as a backup to what's in the add-on installation instructions.
It's amazing how many things are easily troubleshot by having a clean, easy backtrack route!!
(This is partly me writing a 100 times on the blackboard that I should ALWAYS do the above as well...) Hope it helps...!
Though I often don't bother, a good common sense 3-step approach to safely making any changes is, starting from an installation that's working fine:
1) make a BACKUP COPY of each file you're gonna modify, BEFORE touching it;
2) keep track of what you did by COMMENTING IN THE CODE where the change is made, y'know:
// MYCHANGE: this is what I did right here
and also, especially if you're making lots of mods, keeping a Changelog, a list of what you did where, basically, copy your MYCHANGE notes with filename and location (eg: line number).
By commenting with a standard unique tag like MYCHANGE, you can use any text "find in file" routine (they're in lots of text editors and standalone utilities) and find all of your changes in all program files in a few seconds. (This is good for replicating your mods after upgrading GL.)
3) (Especially with lots of changes) check your progress by running GL after each mod to make sure it STILL WORKS, to catch errors early.
Doing the above actually becomes fairly automatic and doesn't take much time at all. With that stuff, you can always step back from an error to a working version by undoing your recent changes (and in extremes, roll back to the backup files that definitely worked). And it's real easy to zone in on where the problem may be when hitting a forum like this!
Also, this system definitely comes in handy when installing integrations, like Gallery, as a backup to what's in the add-on installation instructions.
It's amazing how many things are easily troubleshot by having a clean, easy backtrack route!!
(This is partly me writing a 100 times on the blackboard that I should ALWAYS do the above as well...) Hope it helps...!
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 11:11am
By: Merlisk
[QUOTE BY= Dirk] COM_allowedHTML() is a function in lib-common.php
You didn't say which version you're on and whether it's an upgrade or a fresh install. If it's an upgrade, you may have forgotten to upload a few of the new/changed files ...
bye, Dirk[/QUOTE]
I had 1.3.8 and upgraded to 1.3.8sr2 via a fresh install. I then copied all of my custom plugins and images back into the new directories. I certainly haven't changed any of the core files except, of course, config.php
I'll go check lib-common.php now to see if that's my problem.
You didn't say which version you're on and whether it's an upgrade or a fresh install. If it's an upgrade, you may have forgotten to upload a few of the new/changed files ...
bye, Dirk[/QUOTE]
I had 1.3.8 and upgraded to 1.3.8sr2 via a fresh install. I then copied all of my custom plugins and images back into the new directories. I certainly haven't changed any of the core files except, of course, config.php
I'll go check lib-common.php now to see if that's my problem.
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 11:20am
By: Merlisk
[QUOTE BY= Merlisk]
I'll go check lib-common.php now to see if that's my problem.
[/QUOTE]
One thing I noticed in lib-common.php is that it appears to use the old variable names in the function COM_allowedhtml(): $_CONF['allowablehtml'] and $_CONF['adminhtml'] ) and not the new ones: $_CONF['user_html'] and $_CONF['admin_html']
Am I just missing something obvious? Please remember that I don't know PHP very well. Thanks for the help so far.
I'll go check lib-common.php now to see if that's my problem.
[/QUOTE]
One thing I noticed in lib-common.php is that it appears to use the old variable names in the function COM_allowedhtml(): $_CONF['allowablehtml'] and $_CONF['adminhtml'] ) and not the new ones: $_CONF['user_html'] and $_CONF['admin_html']
Am I just missing something obvious? Please remember that I don't know PHP very well. Thanks for the help so far.
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 11:29am
By: Merlisk
[QUOTE BY= Merlisk]
Am I just missing something obvious? Please remember that I don't know PHP very well. Thanks for the help so far.[/QUOTE]
I added the two "old" variables back to config.php and all works great:
$_CONF['allowablehtml'] = '<p>,<b>,<i>,<a>,<em>,<br>,<tt>,<hr>,<li>,<ol>,<ul>,<code>,<pre>';
$_CONF['adminhtml'] = $_CONF['allowablehtml'] . ', <div>,<table>,<tr>,<td>,<th>';
Someone with better programming skills than I have will have to address why lib-common.php doesn't handle the new ones.
Thanks for the help everyone.
Am I just missing something obvious? Please remember that I don't know PHP very well. Thanks for the help so far.[/QUOTE]
I added the two "old" variables back to config.php and all works great:
$_CONF['allowablehtml'] = '<p>,<b>,<i>,<a>,<em>,<br>,<tt>,<hr>,<li>,<ol>,<ul>,<code>,<pre>';
$_CONF['adminhtml'] = $_CONF['allowablehtml'] . ', <div>,<table>,<tr>,<td>,<th>';
Someone with better programming skills than I have will have to address why lib-common.php doesn't handle the new ones.
Thanks for the help everyone.
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 11:36am
By: Dirk
lib-common.php does use the new variables.
As suspected above, you seem to have failed to update lib-common.php when you installed one of the recent security updates (actually, I'm only guessing here since you still haven't stated which version you're on ...).
bye, Dirk
(edit: Oops, sorry, you did say which version you had. So make sure you're using the correct lib-common.php - it seems like you're using an old one)
As suspected above, you seem to have failed to update lib-common.php when you installed one of the recent security updates (actually, I'm only guessing here since you still haven't stated which version you're on ...).
bye, Dirk
(edit: Oops, sorry, you did say which version you had. So make sure you're using the correct lib-common.php - it seems like you're using an old one)
Re:HTML tags stripped in 1.3.8sr2
Posted on: 11/26/03 11:37am
By: tsavage
[QUOTE BY= Merlisk]I added the two "old" variables back to config.php and all works great:[/QUOTE]
Good that it's working, but I think by doing that, you're basically bypassing the security in the security upgrade!
Good that it's working, but I think by doing that, you're basically bypassing the security in the security upgrade!
Re:HTML tags stripped in 1.3.8sr2
Posted on: 12/31/03 03:05am
By: Anonymous (eemo)
im also having the same problem.
I did an upgrade from 1.3.6 to 1.3.8sr2, and now most of my html tags are stripped in story submissions.
I want to be able to allow ALL tags. isnt there a simple way to do this, without having to define ALL html tags explicitly?
I did an upgrade from 1.3.6 to 1.3.8sr2, and now most of my html tags are stripped in story submissions.
I want to be able to allow ALL tags. isnt there a simple way to do this, without having to define ALL html tags explicitly?
Re:HTML tags stripped in 1.3.8sr2
Posted on: 12/31/03 03:54am
By: Dirk
[QUOTE BY= eemo] I want to be able to allow ALL tags.[/QUOTE]
You don't want that, believe me.
[QUOTE BY= eemo]isnt there a simple way to do this, without having to define ALL html tags explicitly?[/QUOTE]
You could disable the HTML filtering in lib-common.php. If you do that for your non-Admin users, expect to be hacked within a few hours ...
bye, Dirk
You don't want that, believe me.
[QUOTE BY= eemo]isnt there a simple way to do this, without having to define ALL html tags explicitly?[/QUOTE]
You could disable the HTML filtering in lib-common.php. If you do that for your non-Admin users, expect to be hacked within a few hours ...
bye, Dirk