Wedge

The most well known is Highslide, but Wedge has its own ;)

In other news, remember I said about the ob_sessrewrite rewriting stuff being split up into multiple functions for clarity? I found another reason I would do that, or at least part of that.

Specifically, I'm working on WedgeDesk a bit, and there's a point where a link to a user's profile might be retrieved via AJAX. But because it's sent back via AJAX, the user name isn't reformatted.

Now, I know I can invoke the output buffer callback manually but when the entirety of what I'm sending back is:

...it almost doesn't seem worth invoking the entire buffer operation for that.

This bit me in the arse today.

Errors that are genuine errors and tracked through PHP's error handler will have file and line numbers attached because they're passed from PHP itself. But errors issued through fatal_lang_error and fatal_error, that when passed to log_error... they will not have file and/or line numbers.

There's a certain logic to that, actually, in that there's not really a need to pack out the DB with file/line numbers when it's issued by the code itself in response to a user event/other failure condition, rather than an 'error' in the classical sense.

Trouble is, this also means plugins that call fatal_lang_error also won't get logged as being under their plugin unless they specifically pass their plugin id to the error handler, which is kludgy at best.


There's two courses. Either way I can grab the backtrace and get the file/line it came from. The question, really, is whether for general errors (rather than undefined variables etc) that the file and line should be logged. From a debugging perspective it'd be useful, but I'm not sure the user needs to be presented with the file/line every time.

What I'm going to do for now is to keep it mostly as it is, but if no file is found, grab the filename, identify if it's a plugin or not, and then bar logging the file/line number. But the option's open if people want it.

(I'm also debating providing the full backtrace in the error log for debugging purposes, which would be very useful sometimes.)

Well, it is a blurry font but because of how it was made, not because it was trying to be a 19th Century style by design. The story is rather interesting, actually.

OK, the issue as was originally pointed out is that calling add_plugin_css_file will create a new file in the cache, rather than integrate it into the main single CSS file.

There are both good and bad points to this, and it sort of bothers me that it would be left to plugin authors. If you add it on every page without fail, e.g. there is a bandwidth benefit yo getting it into every single CSS file that's cached, with the downside is that cache evaluation goes up every page as extra paths are evaluated.

On the other hand, if you indicate an extra file to be loaded, that goes through the minifier and is then essentially cached with a long life time on it, but it is a second HTTP request. Now, that might not be best, but I'd argue it might be preferable to the hordes of cached CSS files.

Right now, for example, I as a logged in Chrome user get chrome-member built. It's also possible that I might have triggered the guest version for Chrome also to have been cached. Then I add a style sheet that appears to both guests and members, but not every page.

Now I have chrome-guest, chrome-member, plugin-chrome-member, plugin-chrome-guest. Now multiply that by permutations based on browser sheets, and plugin combinations that might emerge. 3 plugins with their own stylesheets that may or may not be loaded at the same time gives you 8 permutations of CSS, multiplied by guest/member, multiplied by browser branches.

I figured it wasn't worth the effort and that it was better not to go down that road at all.

Hmm, this does solve one issue that Nao mentioned to me, that plugin CSS files weren't integrated into main CSS files (which I thought was a bad idea generally, on the basis that different plugins firing different files meant you might generate a great many cached files without realising it) - though it would solve the problem I had about top level menu items not being extensible without work.

However, I can see the logic of what you're doing. Define "not very efficient". What this will cause to happen is a test made every page load to the CSS files being requested, to see if they have been defined or not, but it'll be for all the files in the current stack (if I understand it correctly)

Ah, I look less at the substance and more of the form. I tend not to look at the code of others unless I have to, but I do look at what is provided and how it operates.

Not that I've seen, put it that way.Of course you can't. Copyright law doesn't protect ideas, only the implementation of those ideas.I look around from time to time to see what's out there, but I don't ever implement anything wholesale without a serious amount of refining and adding my own doses of magic to the mix.