Geeklog Forums

Upgraded to 1.3.8-1sr2 and now I can't save HTML formatting. Any idea what's up?

Did you add the new config variables in config.php?

bye, Dirk

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 still works for me, but I can't open in new window!

What gives?

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?

Well, I've added "target" to allowedhtml in config.php (into
the <a's already mentioned "href" and "title&quot 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?

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

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...

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?

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?

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!!!

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.

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.

---

Merlisk

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

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...!

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.

---

Merlisk

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.

---

Merlisk

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.

---

Merlisk

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)

Good that it's working, but I think by doing that, you're basically bypassing the security in the security upgrade!