Displaying 1 To 7 Of 7 Comments Where Are The Settings For That Plugin? At one of the WordCamps (Boulder I think) Jane was talking about this very subject. She suggested that plugins should attach themselves where it makes the most sense. For example if your plugin deals with comments you would add your menu under the top level comments menu. She suggested that very few plugins should ever add a top level menu. For things like ecommerce plugins it would make sense to grab a top level menu, but for most plugins it wasn’t necessary. It would be great if there were some guidelines in the codex about where to hook your menu. It really is a mess now. » Posted By Steven Bradley On September 15, 2010 @ 3:15 AM The main reason for the links on the front end are SEO. Of the links you mentioned only those on the page in the repository will be seen by search engines. At most you’re getting two links from a single page, albeit on a very strong domain. If your link appears on the site itself then it could generate hundreds or thousands or tens of thousands of links. I don’t mind if the front end links are on by default. In many cases the links are the only reward a theme or plugin author gets for their work. However, they do need to be easy to turn off for the average user. Something as simple as a text box or checkbox in the theme or plugin admin panel. No one should ever be forced to display credit links. » Posted By Steven Bradley On February 19, 2010 @ 4:55 PM Should Themes Have Plugin Functionality Built-In? I see both points of view This is really all I’m saying. There’s more than one point of view here and it’s going to be based on who’s using WordPress. There’s no question that if you want to change themes, while keeping all your functionality, it makes more sense to have that functionality be coded as a plugin, but is that how most people are using WordPress. Often a change in theme means a change in functionality too. When clients approach me to develop a theme they don’t ask for functionality. They tell me they want a theme with a calendar. To them that calendar is part of the theme. The see it as part of the design. Later they come back to me wanting a new theme because they don’t like how the calendar looks or they want a theme that has social media links instead of a calendar. The average user of WordPress doesn’t necessarily see the difference between theme and plugin. Other clients might come to me looking to have me customize a theme they found. Often they chose the theme, not because of the layout or color schemes, but because it included the calendar they wanted. Again they see everything as the theme and not necessarily a mix of theme and plugin. The above is not typical of everyone, but it is typical of a certain class of WordPress users. You can reduce all your WordPress files to be nothing, but a bunch of hooks and widget areas and a css file to style everything. That would make your theme very flexible. It would also confuse the majority of WordPress users who’d be wondering why when they installed the theme it didn’t look like the demo they saw. Are they going to use your theme that requires them to add plugins and widgets or are they going to use the theme that looks pretty much like yours, but has all the functionality built in by default? I think Christina is exactly right in saying that the future of WordPress is shaping up to be less about everyone change themes like they are socks and more about what Drupal is doing, which is to package different distributions around a certain concept. I think you’ll see more themes developed as turnkey solutions for a specific industry. As an example think of a photographer who wants to use WordPress mainly to show off their portfolio and have image heavy posts. That person will need to have all sorts of image gallery functionality, etc. that right now exists as a plugin. Some theme developers will create a design and bundle it with those plugins. Other developers will put the functionality directly in the theme. Like it or not the theme with the functionality built in is going to be the easier one for most people to use and is going to be the one that gets recommended more often by those people. Again that’s not necessarily true of everyone, but it is true for a large group of WordPress users. When someone using that theme wants another look for their site they’ll come back to the place where they found the theme and discover a series of skins (a new css file? a child theme?) that exist to change the theme’s look. Again I’m not arguing that it doesn’t make sense to code the functionality as a plugin instead of placing it directly in the theme, but it does add one more level of complexity for end users and one more place where they can make a mistake. Don’t Make Me Think. Those of us commenting here don’t have to think about adding a plugin. The average end user of WordPress still does. Ultimately our goal as theme or plugin developers is to make their lives easier. For some that will mean coding functionality directly into the theme and for others it means separating the functionality into a plugin to make the theme more flexible. Decide who you’re developing for and code accordingly. » Posted By Steven Bradley On February 10, 2010 @ 4:12 PM From a development standpoint it makes more sense to separate plugins and themes for the same reason it makes sense to separate css and html. Howver it really comes down to the end user. Anyone who’s even capable of having this conversation is on the savvy side when it comes to WordPress. We’re not typical of the average WordPress user. You and I can install and remove plugins in our sleep. It still confuses many an average user. For many people it’s simply easier to have everything inside the theme. One thing to install. One point of contact when support is needed. Even bundling plugins with a theme adds a layer of complexity that’s more than some people want to deal with. Plenty of people still don’t realize you can search and install plugins directly through the admin side of WordPress. I don’t disagree with the idea that if it can be a plugin it should be, but you do have to consider who will be using your theme. It may not be better from a development standpoint, but I’d bet most end users would prefer everything be in the theme since it means less for them to deal with. » Posted By Steven Bradley On February 10, 2010 @ 1:08 AM About a year and a half ago I had the same choice to make. I was very familiar with vBulletin as it’s the software in use at most forums where I participate and I’ve been an admin of a few. I knew what to expect with vBulletin. I thought it worth exploriing other options and the one I was hoping would be the best of those options was bbPress. I still have high hopes for it, but then and now it’s not on the same playing field as vBulletin. I think if the WordPress community can get around it then most of what you’re wanting will find its way in. I do still have high hopes for it and plan on using it for another project. However a year and a half ago I chose to go with vBulletin for the same reasons you mention. I downloaded version 4.0 a couple of weeks ago and want to play around with it before upgrading. I’ll probably buy the license for the vBulletin publishing studio in time too. » Posted By Steven Bradley On December 31, 2009 @ 7:17 PM Is A Plugin Validation Team A Pipe Dream? Interesting thought Jeff. The time is naturally going to make this hard to implement, but from an end user standpoint it makes a lot of sense. @Ron – think of extensions for Firefox. Some host extensions on their own sites instead of through the addons at Mozilla. As an end user I feel a little more secure installing them from Mozilla, but I’ll still install directly from developer sites. The majority will probably get plugins directly from WordPress, certainly those who would most likely benefit from having the plugin code go through some kind of validation. Perhaps WordPress could give more guidance as to a set of standards for developing plugins and only those plugins adhering to the standards could be accepted into the repository. It doesn’t solve the problem, but it could be a step in the right direction. » Posted By Steven Bradley On September 30, 2009 @ 7:27 PM Funny. A sure sign something is spam is when the sender feels the need to tell you it’s not. » Posted By Steven Bradley On April 24, 2009 @ 6:36 PMComments Posted By Steven Bradley
«« Back To Stats Page