Closed (fixed)
Project:
HTML Purifier
Version:
6.x-2.1
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Feb 2010 at 19:25 UTC
Updated:
25 May 2010 at 22:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
wik commentedComment #2
ezyang commentedThanks for the patch! I'm trying to figure out how to make this transition work properly without breaking users autoinstalls (as it stands, if they don't have the libraries API installed and they update their files, everything breaks horribly).
Comment #3
wik commentedEasiest way it's to bundle/utilizing libraries API(two methods) with module, prefixing methods with "htmlpurifier_", but I would consider this one only if there no other choice :)
It's could be done as BC wrapper, which could check if there libraries API installed already and use it if so, or use simplified internal methods if it's not installed.
Comment #4
ezyang commentedI've posted an issue here: #709526: How to gracefully add support for libraries
I've hacked in a BC layer on my local copy (I can share if others are interested), but there's another interesting problem namely now you can't /disable/ the module.
Comment #5
j0nathan commentedsubscribing
Comment #6
ezyang commented#709526: How to gracefully add support for libraries was resolved. Blocking on me removing the dependency and making sure everything checks out.
Comment #7
traviscarden commentedSweet! Subscribing.
Comment #8
traviscarden commentedMaking title more "skimmable".
Comment #9
ezyang commentedI spent some cycles today looking at the new approach, and I've found that we need to be careful about cases in which a user has an old-style installed HTML Purifier, and then they install libraries. Patch needs more work.
Comment #10
ezyang commentedFixed in CVS.