I have just uploaded 1.1.0 alpha2 to Sourceforge. This new version features the much needed WP plugin that lets users configure LightPress from the admin console, and it's also the first version of LightPress to run from the WP plugins folder (well, most of it). In short, you can now try LightPress without messing with your WP files (it was possible even before, but it was much much harder to do).
We have mixed feelings about LightPress running from the WP folder, so if you have an opinion about this (and other LP features too), please let us know by commenting to this post or sending us an email. We still have lots to do (apart from spotting and fixing the inevitable bugs) before declaring 1.1.0 stable, mainly in the WP plugin (checking and setting .htaccess, checking options for consistency, etc.), so you still have a chance to ask for new features.
Whoah - when you said 1.1 would be out soon I thought you meant next week!
I still prefer putting the focus on LightPress. Perhaps the LP-only download could run from WP's plugin folder and the LP+WP download (will commit this soon) will feature the preferred install.
Sounds nice, I am a bit worried by the possible support issues (provided we get more than a few users :) with different file locations. And css/image locations in the templates change too, but that is easy to fix.
As for the WP+LP download, the more I think about it the more I like the idea, as it implies an "unofficial LP patch" to WP.
If you feel like starting the WP+LP thing, I will continue laying out the backend which needs a lot of work.
BTW, when you have time to test 1.1 let me know as I'm sure there are lots of bugs in the code I added in the past three days. Oh, and don't forget to send me that "other thing". :)
OMG, I submitted the comment and that "other thing" is in my inbox…scary :)
Sent. I'll try to test 1.1 tomorrow and have a look at uploading the LP+WP version.
My thoughts exactly - sent the email and all of a sudden you're asking for it here… :)
Please point me to the best place to submit bugs. Should I use sf.net?
I needed to ravamp my template anyways, so it is a perfect opportunity to put lightpress in the mix. [very excited]
After this goes through, I plan on converting from textile to markdown.
Now that lp is a wp extension, you need to avoid duplicate class names for the wp and lp plugins.
I ran into this with preformatter, but it can really happen with anything. Just tacking LP onto the end of the plugin name fixes it.
Plugin doesn't seem to find preformatted_content, but I'm guessing it just isn't using the correct hook to add a field to the query. [only been working with this from 1-4 last night so can't say yet].
Please keep up the good work.
Keenan, good point on the duplicate class names! You can file bugs on SF, and/or post comments here. Both are good. We should have a Trac instance soon.
I will prefix all plugin names with LP before the next release, and I guess Jerome will have to check Preformatted after all the recent changes since I modified it to comply to the 1.1 specs, but had no time to test it thoroughly.
Keenan,
There is no special template tag for the preformatted content, the plugin replaces the values of
'post_content'and
'post_more'with the formatted versions.
Also, I noticed the name conflict earlier this week and updated CVS. Ludo, it looks like you tagged the old version when you released 1.1.0-a2. The new version is LPPreFormatted.php.
Jerome, will fix tomorrow. I have no idea if I broke anything in PreFormatted though, as I wrote above I did not test it….. :)
You didn't break anything, it looks like a cvs update problem. Or perhaps you created the release around the same time that I made that change.
Nice job on the plugin management, Ludo! Once I fixed a minor bug I very impressed by what you've done.
Now we just need a way to make the list of plugins more user-friendly. Listing the active ones first would be a good start, and perhaps breaking up the inactive ones by category.
OMG, the first version had a split list with active plugins first, followed by inactive plugins. Then to be more compliant with the WP plugin management screen I merged the two loops. Ofc I never committed the first version :)
As for adding info to the plugins list, there is already a tooltip that shows the active contexts, maybe it wuold be better to show it in plain text, showing defaults for inactive plugins.
Categories, uhm I'm a bit wary of adding yet another attribute to the base plugin class, that needs to be overridden by plugin authors. But it may prove useful to end users. Have you already got a categorization in mind?
I don't think the contexts should be jumping out at the user, the current interface is fine. It's just that there are so many plugins in 1.1 that the list looks pretty daunting, especially if you don't already know what each plugin does. It needs to be broken up somehow so that it's easier to find plugins you want to activate.
But the list should definitely be split into active/inactive plugins. That makes it easier to manage the ones that are active, without having to sort through the entire list.
Ok, I will try to reimplement the split active/inactive list (it made sense when I started developing the plugin management page, guess programming too close to WP distorts my judgement). :)
As for categories, before implementing them it would be nice to define a base set of values. I don't usually like taxonomies, but I guess we should define a set of possible plugin categories, to avoid the risk of having as many categories as plugins (which would rendere them useless).
I installed Lightpress 1.1.0 on my blog, and noticed two things:
- the menu item for LP does not show if there is the Organizer plugin running (WP bug?)
- the plugins list in WP 1.5 (as opposed to 1.5.1) is very hard to read, as the "green" rows for active plugins are not green
Stuff to remember/check for the next alpha release.