Topic: Need someone with PHP Certification to do $1000+ Custom Sitework PLEASE

[Groovystar]

I need several features installed including a tag system. If anyone has the credentials and the time to work on this and complete it within a couple of weeks, PLEASE shoot me a PM.

[Arantor]

With all due respect, PHP certification will bear very little resemblance to anyone actually capable of doing the work; almost all of the Zend certificate is theoretical and SMF uses quite different methods to achieve it (SMF is compatible with PHP 4.x but a good number of the things touched upon by the Zend certification process are heavily PHP 5.x specific, a lot of which SMF does not use)

If you're looking to shell out $1000, you're talking about 4 days' worth of work at a consulting rate. What else would you be looking for (since a tag system is already available for free)?

[Groovystar]

Thank you for the information. I'll openly admit I don't know a whole lot about this.

I need a mod installation, a "counter" mod installed to display a number on each post a player makes on a given thread, to be enabled or disabled by board. The numbers would be meant to count up how many they made to complete a game event, and be enabled on the board where the event threads are run.

Ability to set permissions for threads similar to the ones set for boards. Allowing members to manage their threads this way--either by banning players off all their threads by use of a personal ban list, or by setting a thread to be invite-only and then listing who's allowed to post to it. Allowing members to hide threads, making them visible only to those invited to them {or, conversely} anyone not banned from them--hiding them from members on their personal block list}.

The list goes on. I have another programmer working with me but not sure if he can complete all of it, there's a lot more that he is working on that I wouldn't ask you to do.

[Arantor]

Hmmm, lots of very interesting requirements. Lots of very complicated ones that will have major performance issues attached (as we have been discovering while implementing per topic privacy in other things)

I think whoever takes this on would also need to sit down with you and understand not only the pure mechanics of what's being required but also the nuances of it; while I'm sure there is a perfectly good logic to how you want to count up numbers per post, it would take someone very familiar with the context to understand if this is what you need or not (it has been my experience that what people need often bears little real resemblance to what they think they want, though of course there are always exceptions)

[Groovystar]

If the numbering on posts is not possible without performance issues, let's just skip it.

The per-thread privacy and membership abilities are the big thing. If we can trim performance costs in other areas to make up for it, I will.

[Arantor]

No, you misunderstood me. Topic privacy as you want to implement it will have big, big performance concerns. Mostly solvable ones, but big things to factor in. We went through a lot of experimentation in implementing it and we're not entirely happy with the performance downsides and solutions we have - it will be a big thing to sort out.

The numbering on posts is probably of little or no performance matter, but without knowing your site or what you do I have no idea as to whether it will actually solve the problem you have. It sounds to me as though it's an attempt to automate something that is hard to automate well where it relies on human judgement.

[Groovystar]

You got it The events are usually a 30-post minimum. Our main problems with it however are the double posts, so I think we can disregard the numbering and just go with installing Live's mod--he said it should be very easy to install. I could even give it a try if someone is standing by.

As for the thread stuff, well, if they are solvable concerns, then I'll be willing to go for it. We just need something. Would there be alternatives that you'd suggest? The idea is giving members more control over who does and doesn't see their threads, though it would be pointed out that moderators would still be able to see everything. The main reason is that having all threads public causes people to cheat in the game and makes certain kinds of plotlines all but impossible.

The invite-only and personal player ban lists would be the most important component to this, though all of it is important.

Labradoodle-360 is someone I've discussed this with too. Maybe we could collaborate?

[Labradoodle-360]

I highly doubt Arantor is interested in freelancing....

[Arantor]

I'm not particularly interested in freelancing at this time, I have more than enough going on without giving you some unrealistic expectation. Most of what I was doing here was trying to make sure you weren't going to be scammed by people that talk the talk but can't or won't walk the walk.

Topic privacy however implemented is a massive task because it needs to be replicated throughout SMF, and there's a LOT of places that's the case. There was a patch that covered it in its entirety for SMF but its author will not be interested in sharing nor allow it to be reshared as it was implemented only for one site and to be used only as a base for implementing it solidly in one of the SMF forks. So far that work is on-going and incomplete and has shown many, many performance issues that can't always be perfectly solved and that performance must suffer to some degree to make it work, for mostly the same reasons the SMF team would advise to turn off post moderation.

For those wondering, it causes indexes to be less selective and less useful as a result; no point having an index for 1k rows when the only possible values are 0 and 1, the index doesn't really help you narrow down rows any.

It's a bit more involved when you have multiple options for privacy but the same problem occurs, it slows down anywhere that requires topic privacy to be implemented which offhand is board index, message index, thread view, posting, feeds, all aspects of moderation, and anything that is pulled by custom code or portals... and there's probably more in there that I can't remember right now. Even having exclusions like 'doesn't affect moderators' have a consequence for performance because you have to determine if the person is a moderator first or not, which all adds to the performance struggles.

[Groovystar]

I thank you very much for this information. I still want to try getting it coded up, but will bear all of this in mind. Because of how important it is, I will look into seeing what else can be stripped down to boost performance to make up for it.