Yes, you can do it. There’s just no reason to do so (with the exception of some scenarios).
WordPress has a plugin system. WordPress has a theme system. Use them as they are intended to be used, please.
I think people are naturally helpful to one another if they have an environment that is conducive to that. Forums are a great way to provide that sense of community. It took more than a year for my forums to really get to that point though. You really have to put in the work in the beginning to foster that community’s growth.
If your users are not helpful to one another, I’d say it’s either a reflection of the environment or that your community still hasn’t grown enough yet.
I literally have no support staff (it’s just me) to run a forum. If I take a week’s vacation, I depend on the community members to help each other.
I’ve been running a theme support site since 2008 (one of the original WordPress theme clubs) and like forums the best.
The biggest advantage is that users will help one another. Half of my support is done by other users. There’s nothing better than waking up in the morning to check support questions and seeing that many of them have already been answered.
Forums are also a natural knowledge base because it takes out the guesswork of what things your users actually want to know. As you get more topics and posts, you have more “knowledge” already built up for users to use. This cuts back on support considerably. Of course, you’ll still get some users who don’t search for answers, but that’s going to happen with any type of system. At least with a forum, you can easily search and link to the appropriate topic with the answer yourself, creating a “web” of linked topics that will only strengthen your forums over time.
Forums give a sense of community. You get to know people and they get to know you on a more personal level. This can be extremely good for business.
Despite what many think, forums are not hard to manage. But, it’s all about your setup. You need to be organized. Completely public forums are a bit harder though, but I’m guessing no one here has a need for open forums since they’re running a commercial theme business.
The biggest thing you should do is make sure the forums are easy to use and cut back on the crap that’s not needed for support. You don’t really need a whole bunch of badges and other bells-and-whistles. Keep it simple. Users are there for support and not much else.
- a support forums (pros: transparent, searchable; cons: harder to provide individual support);
You can very easily provide individual support via forums. I’ve never had any issues to the contrary.
Ditto to everything infuse01 said. There are similarities between the themes. The front page probably shows the easiest-to-spot similarities, but there are many major differences between them that anyone can clearly see set the two designs distinctly apart.
It still amazes me that people from a community built on open-source software can complain so much over what’s been “stolen” from them. Maybe it’s time to start embracing the WordPress philosophy rather than fighting it.
Essentially, what others have said is correct.
However, this should be further clarified just so you know exactly what you’re getting. You can only use the non-PHP code once per site. The PHP code can be used an unlimited number times with a regular purchase because it is licensed separately under the GPL . You do not have to purchase the theme again for this.
Of course, what’s a theme without the non-PHP stuff?
- Non-PHP code and assets: licensed under TF’s regular license.
- PHP code: licensed under the GPL .
Some non-PHP code and assets included in themes may also be licensed under an open-source license (for example, many jQuery scripts). You’d have to look at the individual items to find out more about that though.
I typically code 95% of the theme in about two days time. But, this is because I have an extremely streamlined process that I’ve built up over the past 8 years. So, the actual building of the theme doesn’t take long at all. I just put in two full days of work.
However, it generally takes me between one to two months for a finished product. Most of this is devoted to testing and tweaking. Sometimes, I’ll just let the theme sit for a week or two, work on something else in the meantime, and come at it with a fresh mind later.
I also rarely design a theme in Photoshop, so that’s not really part of my process. I just use it when something in the theme calls for it.
Theme users run into that problem every day with poorly-coded themes. The shortcode/CPT thing is really irrelevant with that. The truth is that the theme user is just out of luck, but that’s the chance you take when you use open-source software.
If I were the plugin developer, I’d offer support to the user (and, yes, I do this). Of course, my entire business is built around support. I also like to keep my customers around by offering them a great service, even when they switch themes.
You shouldn’t need a date field. Every post already has a date field, you should use that.
We just need to know which fields we need, and “date” is one of those fields. The implementation isn’t really that important at this stage.
You might be interested to know that Types plugin might be a good start to build exactly what you’re looking for.
To me, something like that is overly complex for what I need to do. I think I’ll pass on using it. It’s a cool plugin though.
It’d probably help if you thought of CPTs as “custom objects” rather than having anything to do with posts. I think this is where a lot of people get hung up on the idea of CPTs.
Also, when we’re referring to CPTs, we’re not usually just talking about the “posts” themselves. We’re talking about an entire system. Generally, CPTs are part of a system built onto WordPress.
The implementation is largely already defined by how the core handles posts.
WordPress has some standard fields that are available for use, of course. And, you can certainly do things that way if you want.
But, the implementation is defined by the “system” that the developer is building. WordPress just gives you the ability to register a CPT and use a few of its built-in features.
The reason CPTs are in the “wp_posts” table at all is for standardization. It’s easier for WordPress to have some built-in support for such things rather than plugin developers building their own tables. This also allows plugin (and theme) developers to use the built-in APIs for getting data.
If you’re implementing a completely new type of content that’s not a post, then I wouldn’t expect that you’d use CPTs.
That’s precisely what the CPT system was created for. I’m sure I could pull up a few of the original dev conversations if I dug around for them.
Not sure I follow you. Give me some examples so I can see the distinction to which you’re referring.
- WordPress’ built-in nav menu system. It’s built with a unique post type, taxonomy, and metadata. It would not work without custom implementation with tons of custom functionality.
- Log deprecated notices: http://wordpress.org/extend/plugins/log-deprecated-notices/
- e-Commerce: http://www.woothemes.com/woocommerce/
- Forums: http://bbpress.org
But, my users benefit from having their content represented in different sections in the admin. Enter CPTs.
You should be extending the WordPress UI for something like that rather than building CPTs unless you truly have different types of content.
I would like to point out that using CPTs isn’t adding functionality. It’s just changing the UI. All the functionality is already there in the core. The only thing that separates a CPT post from a “normal” post is one field in the DB.
When it comes to registration, that is true. However, custom post types aren’t really about registration; they’re about implementation. CPTs typically rely heavily on custom functionality. That one field in the database is largely irrelevant.
If you’re just registering a “type” and not doing anything else, you might as well not be registering it all. Just use posts. If you’re doing it for the UI, that’s not what custom post types were meant for.