Documentation for plugin authors
Working plugins by January 2014 »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Add-on Manager: Mechanics
« Reply #30, on October 1st, 2011, 06:48 PM »
No, because the manager can't know when it should remove them, at least not reliably, since potentially you're talking about any row in any table. Plus, you run the risk of duplicating rows depending on the table in question.

If you need to do so, add a script in the <enable> block and do appropriate clean-up during <disable>, <remove> or <remove-clean>.

WedgeDesk does this when it auto creates a department on install, because the only way it can know whether to add that row is another query first - and that kind of logic can't be represented in a sane fashion in XML.

That said, give me a solid use case for adding it, ideally with a method to automate clean-up, but at least that can safely avoid duplicates, and I'll revisit it (it's not like the plugin manager is finished right now, it's sufficiently done that it's usable, but there's plenty to do)

Note that the two most common tables you'd need to manually add to (settings and scheduled tasks) have defined interfaces for that purpose, and if there's another table that's similarly likely to be updated, I'm happy to include an interface for that, but I'm not enthusiastic about a totally generic row-insertion setup, at least not without refinements to the idea.
Re: Add-on Manager: Mechanics
« Reply #31, on October 3rd, 2011, 03:06 AM »
Getting back to the DTD, I found the whole process of trying to set out the DTD fairly frustrating, since I concluded that I didn't want to have to set the order for every little thing, so in the end I started experimenting with RelaxNG instead. Similar idea but you write it in XML instead of some arbitrary format, and while validation is slightly more effort, the specification is easier to maintain IMO.

(See, I discovered that even the different miniature plugins I had didn't really conform to set orders of things, and I found it fairly irritating to have to set even the order of name/description/author/website in that order.)
Posted: October 3rd, 2011, 01:23 AM

I've written the bulk of the RelaxNG spec, just debugging it at the moment, it weighs in at 462 lines :/ - and it only covers about 3/4 of the actual specification.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Add-on Manager: Mechanics
« Reply #33, on October 3rd, 2011, 09:05 AM »
There's the thing: once it's done, it's done and it can be used to automate testing of plugin-info.XML files.
Re: Add-on Manager: Mechanics
« Reply #34, on October 3rd, 2011, 11:54 AM »
Also, this one's more for Dragooon and live to answer since I'm imagining they're the ones most likely to use it.

We have the required-functions construct. I'm wondering if I shouldn't extend that to classes and methods; all the really fun and useful extensions in PHP are not functional the way they were in PHP 4, but they're classes.

So I'm wondering if I should rewrite <required-functions> into:
<required>
  <function>functionname</function>
  <class>classname</class>
  <method class="classname">method</method>
</required>

You can, sort of, do some of the method calls through the existing interface - provided that you want a static method, if you don't, you're screwed.

I'm not worried about details of implementation (I'm thinking, ultimately, it would be done through instancing the Reflection API) at this stage, merely curious to know if it would be that useful.

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Add-on Manager: Mechanics
« Reply #35, on February 9th, 2012, 02:21 AM »
Quote
! Remove file edits from the master copy of the plugin info specification. It isn't implemented currently and isn't going to be in future, so no need to document its format. (plugin-info.rng)
The OP needs updated to reflect this.
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin Manager: Mechanics
« Reply #36, on February 9th, 2012, 02:46 AM »
It needs updating to reflect the correct title too. I'll deal with it when I get chance, thanks for reminding me :)
Posted: February 9th, 2012, 02:30 AM

Now updated to actually be more accurate.

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin Manager: Mechanics
« Reply #38, on February 9th, 2012, 08:59 AM »
Well, it still has some useful stuff like dealing with unpacking mods and so on - but the more I think about it the more I am kind of leaning towards what XenForo does - and not having any kind of unpacking on the server. It certainly solves permissions headaches but isn't so friendly.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin Manager: Mechanics
« Reply #39, on February 9th, 2012, 09:58 AM »
I thought that unpacking through PHP would on the contrary ensure that files are all writable by PHP..?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin Manager: Mechanics
« Reply #40, on February 9th, 2012, 10:08 AM »
Making it writable from PHP means exposing it to being writable by the web server. Convenient, sure, but on shared hosting, you have to make it writable to all users since on most shared hosts I've seen, the web server user is not the same as the owner of the files and very often isn't in the same group - meaning that your files have to be world writable by definition.

This is why systems get hacked: folks change the permissions and trigger the system to abuse it. Now, if you're not modifying core files, you limit the damage that can be done - but still all the plugin files are within the cross-hairs, and anything on that server that happens to get compromised, can compromise any and all plugins. Even attachments aren't really that safe - but they're safe in that they can't directly be executed by the server (or at least, on anything remotely sane, shouldn't be able to be executed), though attachments I accept have to remain world writable by definition.

On the other hand, if users have to upload plugins, they get them uploaded via FTP and invariably that just works as expected. The plugin gets uploaded, it's not writable by the web server so it's protected from being infected by any other compromised site on the server.

Yes, it's not as convenient as having something that does it all magically, but I'd argue it's a lot safer and doesn't require what amounts to a workaround.

What's more important: being secure or being convenient? You know as well as I do that users don't actually care about being secure, but they love convenience, and we have to make a call on what we think as more important, because we have to care when the user doesn't.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin Manager: Mechanics
« Reply #41, on February 9th, 2012, 10:34 AM »
Y'know, I simply really like(d) the idea of downloading gzipped plugins from within Wedge... :-/

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin Manager: Mechanics
« Reply #42, on February 9th, 2012, 10:40 AM »
Yeah, it's one of those things that would be very awesome, but the security aspect makes me incredibly wary about doing it.

Certainly it isn't required for alpha and can be shunted back to beta, but given that other systems are doing this exact thing (and they're paid, no less) with little apparent ill-will as a result, it does give me confidence that it might not be so bad after all.

It would certainly encourage people to think a bit more carefully about whether they really need a plugin or not.

PantsManUK

  • [me=PantsManUK]would dearly love to dump SMF 1.X at this juncture...[/me]
  • Posts: 174
Re: Plugin Manager: Mechanics
« Reply #43, on February 9th, 2012, 11:03 AM »
I'll take security over convenience every time (in the past our site has been compromised many times, and cleaning up just takes too much time), but I understand the difference; there will be folks for whom the opposite applies. To massage an apposite saying, you can't please all the people all the time...  :whistle:
« What is this thing you hoomans call "Facebook"? »

MultiformeIngegno

  • Posts: 1,337
Re: Plugin Manager: Mechanics
« Reply #44, on February 9th, 2012, 12:17 PM »
I know you guys don't like Wordpress much, but it does allow (as SMF) to download and install plugins/themes/upgrades directly from the web interface. What technique did they use? Same as SMF (so files with 777 permissions)?
Working plugins by January 2014 »