FWIW, Notepad++ offers 1, 2, some of 3 (there's a popup display for the selection of tabs, much like Alt-Tab does but no jump-to-specific-tab-by-number), 4, 5 if you want, not sure about 6, 7 - well, it doesn't fail on 60MB SQL dumps but it doesn't like it much, 9, 11 and 12.
It has 8 too (clone view in tab context menu).
It's not the uber-IDE but I've found it to be a very nice and capable tool, I certainly haven't found it wanting - except possibly for lack of an SVN plugin that doesn't require the SVN command line tools.
And what do you think of our work from what you've seen so far? :unsure:
trigger_error('Hacking attempt...', E_USER_ERROR);Hmm, it has 4 and 8? I probably need to look at it again. Sounds like it has improved.
Seems like a... not catch 22, whatever it's called when you assume a problem doesn't exist, because you don't have it, but really you don't have it for other reasons.
In absence of anything else, the package manager means mod authors have to do direct edits to achieve things, rather than making use of facilities available. The main consequence of this is mods doing template edits which cause support issues because they then don't appear on some custom themes, or at least not the way they were intended. Adding to that, any theme that does do anything creative invariably fails, which is why so many themes are basically Curve knock-offs as opposed to anything more daring. (Yes, there were designers who do more daring things, but the vast bulk of the time the theme is just recoloured.)
And while there are some huge mods out there (Nao and Dragooon's Aeva Media, SimpleDesk by me and a couple of others, plus the portal mods)
they're still generally not that different, because he knows the reality of how many mods don't work on custom themes, and the support boards are full of it.
The lack of premium ecosystem for SMF also tells me there's a problem.
As for mods, the situation there is marginally healthier, indicating that people generally would rather have new features than themes (at least, there is more effort put into mods than there is in themes, in general)
For example, just glance through the last submitted mods to the mod site:
* adding a user's birthday to their profile summary (in addition to the date which is there)
* specifying an alternative email address for outgoing mail, so that the admin's email isn't used for notifications
* a bugfix for the IE8 jumping text box problem, because obviously that couldn't have been added to 1.1.14/1.1.15 or similar
* two different mods for adding the Google +1 button, one for per-topic, one for per-post
* a nice FAQ mod
* a mod to replace the stats area at the bottom of the board index with a jQuery-based tab solution (which means adding jQuery, and will fail on any other theme/mod that already added jQuery)
* a mod to add several symbols as editor buttons (like 1/2, 1/4)
* putting the page number in the title of the page
Over the three months I was on the Cust team, reviewing mods, the vast bulk of what came in were certainly in the 'small tweaks' category.
That means if a particular mod and a particular theme don't play nicely, it's not related to the systemic issues currently in SMF and its environment, but it's that the theme does something the mod didn't expect, or vice versa - but it means that it can be dealt with on an individual basis. (Even WP has issues in this direction, I would note)
/me"]takes a moment to say he did not intentionally hijack this topic.
Your iPhone app raised my eyebrow, mostly because I need to do something similar. Are the HTML5 apps made to be accessed by the browser, made using something like Sencha Touch, jQuery Mobile or jQTouch, or are they bundled into something like Phonegap to be treated like native apps?
Bugfix mods make sense IMHO. Easy to remove and then install the official update later. Hard for hooks to do this.
Definitely. And this is a large problem. However, fixing it by accepting the poison (of no one doing anything interesting) seems like a bad solution to me.
It's kinda like if PHP had say, "ah, PHP 4 classes suck, so no one uses them. Got it - let's just remove them in PHP 5."
However, something like an "RPG/Shop" mod (a constant request, or at least used to be) is somewhat more specialized and can't always be done via hooks.
Fixing that is a separate issue, though. Overreacting to a problem by fixing it too many ways is a bad fallacy.
Sure. In part, this is probably because building package servers is just plain not documented.
I dunno, having looked around a bit on occasion to help people, I found it very fragmented. I agree that SMF doesn't have an effective set of themes or mods.
1. I don't see why this shouldn't be a "mod", if you will, just one that applies equally to all themes (if the theme has a facility for showing that type of user information.) This is the sort of problem I tried to fix with TOX-G.
2. This seems like a good candidate for a core feature. Ideally, it should be built to that standard (I'd always wanted to see features "baked" as mods before going into the core, not sure if that ever happened.)
3. Bugfix mods make sense IMHO. Easy to remove and then install the official update later. Hard for hooks to do this.
4. See #1.
5. This definitely seems like hook territory. I assume it's got its own area and doesn't touch other sections.
6. This is a harder problem, but if it uses jQuery.noConflict it shouldn't cause issues even if there's a separate version of jQuery on the page. That said, a consistent js framework is a good idea.
7. Sounds like hook territory.
8. Sounds like a fairly basic mod that has no theme problems.
I think the reason for small tweaks being the most common kind of mod is that the whole review thing scares away mid-sized mods
Hooks cannot possibly solve every thing a mod ought to be able to do, and if they are really enforced, you're only relegating to always being in the situation of large only-just-touching mods and tiny tweak mods.
To me it seems Wedge has already been laid out with that lesser possibilities for me as a designer, while SMF is still "full on"...although its focus on CSS-only themes takes away the focus on getting mods out of themes. But at least you CAN still change any template, luckily. I do remember Nao mentioned that it can be done in Wedge too, so its not all bad - but focusing on stylings sends a powerful signal out to any starting designer for Wedge.
But I also see WHY Nao/Arantor wants more features in - more powerful, central developing point etc. I think thats a slightly wrong turn though. Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
1. If your community is producing bug fix packages, we have to ask the question why aren't being made part of the core product?
abcxyzI cannot see any justification for *not* patching it.
2. It discourages people from upgrading. To me, an upgrade shouldn't just be about fixing problems, it should be an overall iteration on what was there before, so improvements (not necessarily new features, but improving existing ones) as well as fixing bugs.
Most of the mod authors are not strong programmers, and invariably look for the easiest route to implement something, which means template edits in the first line of attack, source edits in the second, and almost never taking advantage of the resources actually in SMF to pull some of it off.
Themes/default/basic.tox:
<tpl:template name="we:avatar" requires="url">
<tpl:if test="!empty({$url})"><img src="{$url}" alt="" /></tpl:if>
</tpl:template>
Themes/cooltheme/basic.tox:
<tpl:template name="we:avatar" requires="url">
<tpl:if test="!empty({$url})"><div class="avatar-box"><img src="{$url}" alt="" /><div></tpl:if>
</tpl:template>
Packages/defaultavatar/overlay.tox:
<tpl:alter match="we:avatar" position="before">
<tpl:if test="empty({$url})">
<tpl:set var="{$url}" value="{$settings.defaultavatar.url}" />
</tpl:if>
</tpl:alter>
Warning: This package modifies core functionality of Wedge, and may need to be uninstalled prior to an upgrade.
When you upgrade, the package manager will automatically uninstall this package for you if it conflicts, and it may need to be reinstalled or even rewritten at that time.
* File permissions, and making files writable to PHP, is one of the single most asked questions on the support boards -> can we make mods that don't need to make the core files writable?
* Mods only working on certain versions, people asking whether mods will be updated -> does a mod expressly have to ask for a version, or can it attempt to determine if all the features it needs are available?
* Mods searching for code and not finding it, because the original code has been modified (either by a later version, wherein even the comments get modified sometimes, or by another mod) -> can we make mods that either don't need to modify the files, or can better manage to sort themselves out without having to trip over each other?
* Mods that need to modify templates -> why do they need to modify templates? Does it always have to be a template edit, or is it about the data the templates output? Can content be injected into a template in some other fashion?
making an installer script, but the more we talked about it, the more I felt comfortable abandoning file edits in the base.
It does come up regularly enough. I'm not sure what you couldn't do with strategic insertion of hooks, it doesn't need to be insane.
It's not that hard to figure out. But premium sites can't use it because by definition everything in a package server has to be accessible by a simple GET and as far as I can tell, without any authentication handling.
The thing most people seem to forget is that the bulk of mod authors aren't people just writing stuff to give away - they tend to write it for themselves and their site, then share.
Or better IMO, make the editor buttons configurable to the admin, so if they want to add them, they can. But yes, this could be achieved with hooks (even in SMF) and I don't think it is.
Well, I'd personally debate that it should be a core feature rather than a mod.
But I've seen even large-scale phpBB mods done, well, as lists of file editing, which says to me either there aren't hooks, or they're not really in use much.
That all said, I'm willing to bet that part of the problem is simply that most mods are contributed by people in their spare time, without any interest or desire in writing big and complex mods
I agree, to a point. The thing is, apart from the fact that it doesn't seem to have hurt MyBB or WordPress (and especially WordPress)
I'm not convinced it will restrict to large or tiny mods.
That's really what we have to do: just expanding hooks on its own won't be enough. We have to make everything else be more open to extension too, and upon doing that, almost anything should be possible.
We aren't focusing on Stylings. I just offer them as an easy alternative for non modders who want to have different themes for their users without making it a hassle to maintain.
but they will want more the things they can't imagine yet.
As I also mentioned on Blocweb, adding too many features in Wedge makes creating alternatives less desirable for others. Why create a gallery when theres one built-in?
Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
In contrast, are there any mods that replace the moderating center in SMF2? In SMF11 there could have been more alternatives(was there more? I can't remember) but in SMF2 theres no reason to now. And that moderating center isn't a solution to all moderating needs..
$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);
$http->process();
if its part of what you set out to achieve then that won't matter lol.
Yes, its good..but honestly, why would anyone create a mod that does what Aeva does then? In contrast, are there any mods that replace the moderating center in SMF2? In SMF11 there could have been more alternatives(was there more? I can't remember) but in SMF2 theres no reason to now. And that moderating center isn't a solution to all moderating needs..Quote from Dragooon on June 26th, 2011, 08:46 PM Wedge's theme system is only beyond SMF's, it doesn't remove any of the previous possibilities but has enhanced capability for additional css variations.Quote To me it seems Wedge has already been laid out with that lesser possibilities for me as a designer, while SMF is still "full on"...although its focus on CSS-only themes takes away the focus on getting mods out of themes. But at least you CAN still change any template, luckily. I do remember Nao mentioned that it can be done in Wedge too, so its not all bad - but focusing on stylings sends a powerful signal out to any starting designer for Wedge.Personally, I think it is a more positive turn. Not only does it ensure a system that is powerful and well integrated down to the core, it adds more capabilities for a small time modder to extend upon. It may discourage alternatives, but it doesn't necessarily prevent them. Instead, it helps to improve the existing system with multiple people pouring in.Quote But I also see WHY Nao/Arantor wants more features in - more powerful, central developing point etc. I think thats a slightly wrong turn though. Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
I am not saying to ALWAYS have alternatives..the quality will maybe be worse sometimes, but with Aeva as built-in rather than a plugin, you will not see any evovlement in that area other than what you do yourself. It depends on how you look at it if thats a good thing or not.
Yes, they do. Look at extensions for Firefox, which don't do any "core edits." Chrome has this problem less, but also the extensions can do a lot less. And, for example, the latest "Page Speed" extension is broken in Chrome, and the latest Closure Inspector is broken in Firefox. Both of these use plugin models.
It's good to warn people not to do things they probably don't want to do. I still think there is an established use case for it, just as long as people are careful.
I'm not saying it will, I'm just saying people will go to manual file edits. I personally think (and have heard from many people) that SMF's managing these for you is still a good idea.
Why does this not affect other software? Are you proposing a different (more selfish) audience uses SMF than other forums?
And that's because they still depend on version checking. My proposed method explicitly does NOT check for Wedge version.
It probably does, I haven't spent any time in their ecosystems. But given the mods submitted, the relative skill level of the coders and so on, the majority are certainly not contributed by veteran coders.
, 2005-02-17"]
Actually, I've messed around with doing things like this several times. Some of the solutions I've come up with have involved reading files from a directory, serailizing the information gained from them together, and writing it to a cache (whether database, file, or otherwise.) That may seem roudabout, but I really can't like an idea if I know it's going to be slow and less-than scalable.
Using this system, a registry in the database isn't technically needed, although it could be useful. The gain of not having it in the database is that plugins can be loaded before the connection is made: and this would allow, as an example, plugins to mean other-database support.
But, obviously, a table has clear benefits (and makes it notably easier to upgrade plugins, which is something a lot of systems ignore!) The downside is that all of this information is going to be needed all the time, so everything is going to have to be loaded from the table (not just some.)
...
It would also mean essentially abstracting every internal function call. Imagine:
processFunction('db_query', 'load_settings', array("
SELECT variable, value
FROM {$db_prefix}settings", __FILE__, __LINE__));
Again, macros and such would make this better. Or even just an event system:
fire_event('loaded_settings');
Although you're right, the major problem there is that the function can't mess with the local scope. That's what I like about macros - I wish we could do this:
.. snip longish example that closures basically finally allow ...
And these could be automatically inlined during compilation, and then possibly optimized out if possible.
Anyway, I do agree that extensibility is one of the main things SMF needs to gain... I guess I'm just really hard-nosed about the common methods of doing it :P.
The reason being that I cannot see everything being done with file edits, I need file edits for WePortal which is more or less the first mod for Wedge(Unless someone beats me to it). So please keep file edits, but instead frown them upon.
If he has managed to do Simple Desk 2.0 (a really big mod) using only hooks he may have some ideas that could help you out there.
SD 2.0 still requires multiple file edits (which I swear I said several times)
But since it's become increasingly clear that I'm barking up another wrong tree, I might as well revert what I've done and go with my first plan of enhancing what's there and praying to $deity that my fears are baseless, except I know full well I'm right there.
Anyway. I have more alcohol to drink right now, a hangover for the morning, followed by a 200 mile road trip, just so I can go to a family funeral tomorrow
But since it's become increasingly clear that I'm barking up another wrong tree, I might as well revert what I've done and go with my first plan of enhancing what's there and praying to $deity that my fears are baseless, except I know full well I'm right there.
(See, Unknown's someone I look up to and when he says in not so many words that he thinks I'm working off broken logic, I tend to agree with him. Then I remember that he's younger than me and still managed to achieve so much more than I have so far, and I quietly begin to question myself. I hear my beer calling.)
link=msg=263240 date=1309240621]
I'm 25, so I guess I was about 17 when I started working on SMF. Certainly have learned a few things since then.
Dunno about whizzkid, essentially I spent the couple years after high school working on SMF before I got a job. It's much easier to get a lot of things done when you don't have other obligations etc. yet. More a function of circumstance.
-[Unknown]
How old are you, Unknown?
If you're younger than Pete is, does that mean you were one of those Dragooon-like wizkids back when you started SMF?
I hate those fucking wizkids, they always end up being faster and better than me :niark:
You are 8 years older than me...meh old people!
Why, thank you!
Arantor, at some point you are going to need to rely on versions or you will never move forward. You can loosely couple but if you overdo that, you wind up with Limp instead of Wedge ;)
I want mods that do not have to rely on version checking. I want to avoid all the explicit checks that SMF has to make.
It also doesn't discourage abandonment - mod authors, generally, want to do as little as possible to maintain their mods.
version-emulate
(And if I can encourage them to do it a better way by making it less work for them, awesome.)
I was careful to avoid making more edits than necessary
What tends to happen is that mods which hit up the same place tend to collide, for the obvious reason
but any mod that then tweaks the layout (or has a different layout entirely) is going to conflict.
1. It makes people have higher permissions than they actually need.
2. It is a major cause of people hitting mod_security errors where they throw 777 permissions at everything.
3. It is very likely also a contributor towards installations being compromised and hacked.
That was partly why the krisbarteo hack in 2009 was so successful
While it can be 'made more reliable', I have lost count of the number of support issues that emerge every single day with SMF because of file permissions.
I could go on, I can find you more and more reasons to discourage file edits, and I hope this is enough to discourage mod authors where possible.
we make the user have to manually enable it first, to understand all the consequences. Plus, we can manage it through the repository to advise the user that manual edits will be required.
But I think any more than that will be a case of putting out the tools and hoping developers make use of them
I'd like to reiterate my original idea.
Disable file edits at least until Wedge is out of beta.
If people rely on file edits when they can't find a hook, we'll never get people to get us to add hooks.
Other than for file edits, why do I have to rely on versions?
And the stuff I wrote 10 years ago... with one exception, it all still works on Windows 7. That particular exception is because of an API that was deprecated back in 2000, and naturally doesn't exist now. If you can do this on an operating system, why can't we apply the same basic techniques to programming in a higher level environment?
I want to be able to port my mods to Wedge. I want to be able to write some of the other mods I've thought about over the last 2 years, except the frustration involved in writing most of them in a way that won't cause me to do support is why I didn't.
Sounds ambitious, and in a way i see what you mean, I like to write themes or mods too, that will always work, or don't rely on anything changes etc. But i think thats an utopia, as long as the host script changes, you need to change with it. And the host script need to be possible to change, your knowledge will change, technologies arrive that require it etc. I bet your old programs, while they still run, could use updating still. Being content with it "just working" doesn't bode well for innovatism IMHO...
But I've love to see me proven wrong of course lol. :)
Oh, of course they could be updated, because I've learned a great deal in the last decade. But here's the thing: won't someone PLEASE think of the users? :P
Now, if "you" can manage to keep mods working across version updates, I'll love you forever; having to (re)install mods every time the host app changes isn't fun (can anyone say "SMP minecraft server"?)
Anyway, to simplify my point, one site I administer is using SMF 2 RC5 will plenty of mods...now with SMF 2 Final, I am reluctant to upgrade since it will involved the same amount of work during the initial installation; that is checking if the mod is compatible with the version and re-install...
it would be better to simply upgrade the forum software only without all the hassle of checking the compatibility of the mods since to me it come from the same branch
But maybe you should back up abit...what exactly IS the purpose of Wedge? A forum alternative to SMF with extras? or a "soon-to-be-core" script that can accept plugins, and just happens to be a forum in nature..? Not saying one or the other is better in any way(done my share of making SMF into something more for example lol) but whatever direction you are headed will also influence the question of using file-edits versus hooks/plugins.
So you didn't go to a professional university?
Wise words.Quote from Bloc on June 29th, 2011, 10:28 AM But maybe you should back up abit...what exactly IS the purpose of Wedge? A forum alternative to SMF with extras? or a "soon-to-be-core" script that can accept plugins, and just happens to be a forum in nature..? Not saying one or the other is better in any way(done my share of making SMF into something more for example lol) but whatever direction you are headed will also influence the question of using file-edits versus hooks/plugins.
If this is the way for Wedge, I say go for it... maybe you won't get the same level of contributions from external coders (since it's a more "controlled" product), but you'll make your end-users and those who administrate the forums very happy. ^_^
I think that administrators can be made happy without having a rigid product. Ultimately I see both extremes as "unhappy administrators" just for different reasons.Quote from Paracelsus on June 30th, 2011, 10:30 AM If this is the way for Wedge, I say go for it... maybe you won't get the same level of contributions from external coders (since it's a more "controlled" product), but you'll make your end-users and those who administrate the forums very happy. ^_^
-[Unknown]
link=msg=263307 date=1309420832]
Presumably, not a ton of code has changed between SMF 2.0 RC5 and SMF 2.0, right? So in theory, this sounds right. I'm not sure what it means to check the compatibility; from context, I assume this is some manual process?
Let me ask you this. The mods you have installed now, did you have to make any manual edits to install them all successfully? I don't know if you have a bunch or if you use themes, but if the answer to either of those is yes, I presume you had to do manual edits, and you're wanting to avoid making those again, right?
I assume there is an update package for SMF 2.0 RC5. I'm guessing it does not apply cleanly on top of your existing mods, right?
-[Unknown]
So yeah, one can spew all over bad decisions, poor coding, not enough visions
I do agree that most mods should be made with hooks. I just don't think it's possible for every single mod, and I think it's limiting. If the average user has more than one mod that does direct edits (excluding updates), that may be a bad thing.
And again, some of the issue is "contention" for certain areas of SMF that are common to modify. For this reason, conflicts and problems and order-of-installation are much larger problems. Every area of contention definitely should be a hook, solving that issue.
But you note that it won't go away, I'm just giving a real-world use case.
That doesn't seem crazy. That said, if you add a hook for every possible file edit, I promise you that you'll regret it later. More on that later.
This is a fairly easy argument to refute. I'm going to keep it brief because it's getting late, and I need to get some sleep, but:
A number of reasons (although if there's enough semantic hook detection, this can be mitigated.)
A well developed mod will be shipped as one version, even if there are multiple popular current branches of Wedge currently being used. In some fashion, different hooks need to be installed potentially for different versions - consider that Wedge 2.0 adds a new hook that this mod wants to use, but in Wedge 1.x, it needs to use other hooks (or file edit the hook in, for BC.)
This can be mitigated by some sort of hook detection, but this has its own set of problems. One option is to run plugin init code on every page view, but this has performance problems with many mods. Another is to re-run hook init logic for every different version number internally and/or whenever plugins are installed/removed, so the logic can be updated and cached. This has its own complications, mostly that it isn't simple to write.
I don't know the specifics, but it looks like it was a file-uploaded-but-shouldn't-have-been-allowed type of issue, or maybe a CSRF. Assuming this is true, and attachments or cache are writable, you're probably screwed no matter what.
I don't think users like dealing with order-of-installation issues, or contention issues, or any of those things. I also don't think they like dealing with manual edits or uploads, incompatibilities, or etc. either. Users also don't want indirect problems like core development slowdown or not being able to upgrade because a new version has different hooks.
Trying to think only of the user often ends up ignoring a significant part of their concern. Best to think of everyone and only prioritize the users where possible, IMHO.
That said, I know that you care about the users already from past conversations, and that's a very good thing. I'm not knocking that at all.
This was just one of the historic "bad decisions" we made. This came up several times while we were working on the feature. I noticed it and considered it, we talked in the dev team about it, and the team discussed it. But usually briefly, and the answer was always "ah, it's fine to reinstall every time."
At one point, someone had proposed a more robust system, that tracked exactly what to do, installation order if necessary, and did a dry run unapplying, updating, and reapplying, and told you which mods weren't compatible that way. I don't remember how it totally went, but we didn't do it because we figured the effort wasn't worth it.
Presumably, not a ton of code has changed between SMF 2.0 RC5 and SMF 2.0, right? So in theory, this sounds right. I'm not sure what it means to check the compatibility; from context, I assume this is some manual process?
These are a common concept in integrations now, and something I strongly recommend for Wedge. I would imagine that file edits might be a permission.
I think that administrators can be made happy without having a rigid product. Ultimately I see both extremes as "unhappy administrators" just for different reasons.
Although I value a lot SMF's flexibility of being able to change almost every imaginable thing in the system I just love mods like SimpleDesk (which is a very nice piece of software, congrats Arantor!) or AEVA, the way they install, uninstall and upgrade without issues with the core and then the amazing gui and amount of freedom and features they provide inside the mod itself (which to me cover 99% of the aspects I would like to be able to customize in such a mod).
It was mostly a statement in response to Unknown's question about upgrading from 2.0 RC5 to final being a full update (which it is, unless you're insane enough to go through and make the changes to each file by hand, as I did in Wedge's case)
Ah, that means I've been reading between the wrong lines.
Yes, that's the plan. I look to SimpleDesk on this one: there are some places I do actually do template edits in SD 2.0
the track-IP screen or the manage-attachments screen unless they had very, very good reason (and SD does, in both cases) - and since they are uncommon templates, I'd never had a conflict.
Not all things are expressly hook points as we normally think of them.
My point here, I guess, is that mods can be written with other mods in mind, if the author chooses to be careful about it.
(It would also be quite hacky, I think, but it would certainly solve some of the issues.)
it should be possible to do some of it in the Wedge ecosystem, and it was more a comment to encourage people to stop and think for a moment.
(This sort of behaviour is not unheard of even in the forum ecosystem. Whether it's desirable is another matter entirely.)
But it's hard work because of the nature of changes in SMF between the two branches and in all honesty, I'd personally rather have not bothered with the dual packaging. (In fact, I shied away from making mods for both branches at once, simply because invariably I had to write it twice, because everything was different, most importantly $smcFunc vs db_query)
Users, generally, don't seem to have a problem with mods being in separate packages for different versions
what hooks it had available to use, and thus what hooks a given mod could use, while the main site would know all the hooks in every version.
It was suggested before that SMF's mod site could attempt to perform installations on different versions and see if the file edits were successful
I would point out that it is our intention not just to throw out a release and then declare it feature frozen for the life of that branch. We always planned to handle it iteratively, in a kaizen-style of development whereby each version adds something as well as just bug fixes, some method of improving how we do what we do - instead of just giving users a 'this version just fixes some bugs' reason to update (which is a push factor), we want to give them some pull factors too.
It was a file being uploaded that was able to be executed. Which then tries to infect any PHP file it can modify.
Order of installation is an issue that, really, only comes about because of multiple mods doing file edits in contentious areas
people are prepared to pay others to install mods does bother me slightly.
they're no longer edits.
the ability for a hook to load a file when necessary.
There is, buried in the depths of the upgrader code, some facilities for this but I don't think they're enabled and even if they are, I don't think they work properly.
(much as I find the idea weird: why run something without learning a bit more about it?)
Users should check that mods have been updated for 2.0 by looking at the mod's page. Especially since each RC has brought some interesting changes with it (as it happens, there are behavioural changes between RC5 and final that some mods will have problems with)
Oh, and before I forget, as it's relevant. You asked what version-emulate was.
I am only too aware how users are becoming 'trained' to accept stuff.
That, and standardizing data loading, SQL querying etc.
SMF's permissions system allows for 'in a board' and 'not in a board' permissions, but nothing more configurable or flexible.
Right now we're arguing over how big the forest in the landscape is, or the size of the cottage. We're not arguing that the picture needs sky and land, and that it needs trees and maybe that cottage - only the relative sizes and the fine points.
but also so will breaking them up into manageable chunks (that can be manipulated in the subtemplate loader now)
SimpleDesk is another similar scenario: I don't see anyone else ever writing another helpdesk for SMF - not only is it pretty niche, but I think I did enough of a good job with SD that another isn't needed unless SD is wholly unsuited to a given task.
But I find that's limited mostly to the 'new functionality' add-ons, not the 'modifying existing functionality' ones, I foresee there will always be new ways to do that, and people always wanting to do so. But I figure if I attack the most commonly requested mods, to deal with the general cases, it doesn't negate anyone else doing it, it just means that people can focus their attention on new things instead of finding existing things to rehash over and over, if that makes sense.
I've not looked at SMF or Wedge's hooks, but how can this not be possible? Doesn't a hook run code? Can't code include files?
Or try a diff between the two release trees, which probably wouldn't apply cleanly in most cases.
It means your stuff is wrong and has to be rewritten now, no matter what.
then I don't think there's generally any good reason for a theme ever to change the meat of an administrative section.
but potentially they could be used for hooks (e.g. instead of something liek query_see_board.)
Well, I agree with designing in a way that this is not necessary to think about. Just like security; anything that can be made automatic is better that way, as long as it doesn't have other downsides
Sure. Although that can't do everything. Imagine if the recycle bin functionality were to be made a mod (in fact, I'm fairly sure it was at first.)
Then you need to at least do code review.
So you're screwed that way too, even without the package manager needing things writable.
Not true. Two plugins hooking the same hook can also cause issues
That doesn't seem wrong to me, in any case. That said, if it's becoming necessary, that seems bad.
Well, unless major changes happen again, as did with SMF 2.0. What if they separate out the core, and now all the syntax for everything has to change again? Are these "maintenance" areas really big problems between e.g. 1.1.1 and 1.1.2, etc.?
Yeah, I know it was there, initially it wiped out installed.list IIRC. I think we moved to a database to remove the requirement of that file being writable, and may never have fully moved everything over.
Which means, in other words, that they were betas. And if the last RC and the final and major behavioral changes (which I gather it did), then basically a release candidate was never made.
This sounds like a bad idea. I would rather just say "hey, this version says it won't work, want to try it anyway?" I even thought it did that.... but I guess it probably doesn't.
This always felt like a hack to me, actually, and I never felt completely comfortable with the way board specific permissions kinda shook out. They still confuse me, which is a bad sign.
At least we're not (or at least I hope I'm not) arguing about the color of the bikeshed.
Does SMF's system yet allow for multiple subtemplates to be used on the same page? Example: "poll", "poll", "calendar", "post_list"? I think I mentioned on SMF I have since moved to this system (and TOX-G uses it too.)
Actually, a reason not to have things in the core also is attack surface.
Sure, except it can narrow the mindset.
Let me explain what exactly my edits did, and I'll let you judge for yourself. FWIW, I'm of the view that these are acceptable, not necessarily desirable.
(and yes, I did account for that in the maintenance... I think I did, anyway... have to check that now, it's been a year since I wrote it)
Something like that would have to be done as manual edits, I don't think there's any way around that - but on the other hand, something like that should be in the core anyway.
(e.g. SlammedDime's SimpleSEF periodically makes sure it is the last hook called - though I recognise that it's possible a second mod will attempt to do the same and cause issues that way, but I gotta say that's very much an edge case there, order of execution is not that much of an issue for the *majority* of mods)
Yet there are a great many mods that interfere with version updates and vice versa.
That's the problem: it's all in the database, and the upgrader doesn't deal with it properly. The file is still present, though, it just contains the timestamp of the last install. Quite *why* it does that, I have no idea.
You can't do it that way: remember we talked about multiple versions being handled in the same package? There's your reason not to do it that way. Imagine you have a mod that states it supports 1.1.13 and 2.0 RC5, and you're on 1.1.14. Which set of instructions should it use as a 'default' fallback?
Board permissions confuse a lot of people and 2.0's move to using profiles for boards is even more confusing. I know the entire setup needs to change but I'm not yet sure which way to go for the best.
From my perspective, the calendar as it stands is not that useful, so having it in core is not necessarily the smartest move, but if it were to be more useful, there would be more reason for it to be present.
I don't think there's any way to avoid that, though. Every time someone writes some code and releases it, it adds to the total substance of what's available - and every time that happens, there's one or more people out there who won't roll their own version of the same. From my POV, I see it as priming the pump for the most part, because I know others out there will think of ways to expand on what we come up with, and I know I won't be writing every possible permutation of mod either, so others who want it differently will invariably come up with their own spin on it.
I think they're fine an all "hookable" in some fashion, although whether hooks would necessarily be forethought for all these areas is uncertain. Th only area I see a theme potentially wanting to touch is the IP one, and probably not.
Ah, good. While I think no one uses that feature (at least they didn't used to), I think it's a good feature. It came from YaBB SE and probably even YaBB, originally.
Still don't agree that the core should have a working kitchen sink that churns out boiling hot and cold water
Well, edge cases are important. Even if just knowing about them and documenting them.
In this case, I think I've seen before a "hook weight" where you can basically say "I want to be first"
I don't see the point of picking a specific version to emulate when it seems as if the software can figure this out itself.
Originally we set out to move to the DB and that was it.
And as much as I hate UAC the way it works in Windows, I like the concept of opting in to having lower privileges for a period of time.
I would still take it out (if I ran a forum) and just drop a link in my menu to a Google Apps calendar (if I even needed a calendar.) I would also remove PayPal / any payment stuff (in fact, that would be the very first thing I'd do) and if that HiveMail or whatever mod got integrated I'd remove it too. I'd remove the moderation center, dumpdatabase, any friendly theme editing features (and especially the viewfile thing in the error log viewer)
block me from logging in whenever a hacker wants to spam my account to lock me out
I'd add code afterward that would do e.g. $actionArray['x'] = array('y', 'z');. While "ruining" the style, this didn't ever break and my mods were fairly low maintenance.
ViewFile thing... hmm. I can't see any huge reason to get rid of it, and I can see a smallish reason for keeping it: people *do* post its output when things are broken, because when you have file edits, it can show what's broken. Though for the most part I'd probably argue it doesn't help, but that doesn't mean it hurts to keep it either.
* PayPal, because I take the view (much, as I think the team did at the time) that anything payment related, I'd rather have that in the core than a possibly unmaintained mod, for security purposes
* HiveMail... not sure what you mean? Certainly there aren't any mods named that on sm.org.
In all the time I have been giving support, I have seen some people in cheap servers with no FTP access nor a good control panel, so the only way they have, if they ever need to edit a file, is using this feature.
If file edits are going to be ever needed I would even suggest you could extend that feature to all the files (not only the Theme files) for that people without FTP.
UAC hits you with a heavy hammer. Unlike sudo and most other systems, it asks you *every time*, resulting in user training. It's also for anything that isn't something a standard user can do: for example, UAC would require a password prior to moderation.
I figured I'd toss my two cents in, as someone who more or less, has always intended to go around SMF (except for bridging authentication) as much as possible. That, and I'm not a web developer, so it is easier for me to work that way and fix my own mistakes without affecting an adequate solution. I also have a tendency to react without thinking things through simply because of some of the things I've seen in my limited experience .
File edits are a pain in the ass to maintain between versions and so are hooks. I don't think either is going to change developer behavior sufficiently to be worth picking one or the other solely for that reason.
If you provide Hooks, you need to also provide File Edits to avoid Unknown's concern of people causing trouble that way.
If the real, and only concern, is the size and quality of mods...you are probably better off coming up with positive incentives to create certain types, and a certain quality, of mods rather than relying on the method of modifying Wedge to do it for you. I've got no good idea how to go about that simply because I've never tried to foster a developer community around a project outside of a situation where everyone is being paid to care about said project.
A dream Wedge would be that stuff like Arcade and Gallery etc won't have to be rewritten to accommodate some core change each time there's a revision.
When it comes to the gallery, I see you're using SMF, so you'll definitely to have to upgrade to Aeva Media 1.4 if you want to then be able to import it into your Wedge forum (although TE might wanna support SMG as well, but frankly I wouldn't do it if I were him. There's already a perfectly well written upgrade script in AeMe.)Quote from Clara Listensprechen on July 12th, 2011, 05:20 PM A dream Wedge would be that stuff like Arcade and Gallery etc won't have to be rewritten to accommodate some core change each time there's a revision.
Plus, I believe there are security issues in SMG that were fixed in AeMe ;)
As for Arcade, it's a big mod AFAIK and I doubt it'll be ported over. At least not easily. Perhaps I could give it a try, but it would have to be BSD'ed first.
I intend to do fresh installs of Gallery and Arcade rather than import.