I don't believe so, but you could create polls and surveys and then link them externally.
http://www.limesurvey.org/
I'll see what I can find as far as a survey you could imbed into your templates.
according to the site linked, its been patched.
Hi:
Things that I would like:
WYSIWYG EDITOR
- Definitely, a better article editor, like TinyMCE
ATTACHMENTS & COMMENTS
- Attachments that REALLY work: both files and images
- Comment system that REALLY work: this feature need some major improvement
ARTICLES
- Scheduled Publishing (using a crontab): automatically publish articles or issues at some time in the future. For articles, you can schedule the following actions:
- publish, unpublish, show the article on the front page, remove the article from front page, show the article on the section page, remove the article from the section page.
- Article lock: so only one editor can be working on an article at a time and if someone try to work on that article gets a warning
- Prefix: posibility of using both date and user defined prefix, not only one at a time
- A news ticker: in ajax or JS, perfect for flash news, from selected categories or type of articles or both, etc
- News by email: again, this would be done by setting a crontab
- Related articles
- Times read in article: option to have this as a function for public view on each article (article template) or private in admin area, it would be good to know stats about the articles we publish
CONTROL ACCESS
- To certain articles or sections (ex, subscriber-only articles, etc)
- integration with Simple Machines Forum OR
- a built-in Phpcow member system (where admin can set permission to users)
TEMPLATE PREVIEW:
An option to see the entire site on a preview, not only the main page
MAJOR IMPROVEMENTS ON:
- VOTING SYSTEM
- GALLERY
- CMS
- SEARCH
- most popular articles
- Knowledgebase on phpcow.com site
- BETTER User support (because we are paying, this is not opensource)
Regards
Some interesting ideas there Bobby! We've got quite the 'wishlist' going now!
TinyMCE can never handle the expanse of work needed to be done in PHPCow's editor.
Article Publishing scheduling is already there. Use the Dates feature while you add articles. CRON is NOT the answer.
Attachments really work so not sure what you meant by the same?
News by email: Do you think a shared host with a limit of 200 mails/hr will ever work? All shared hosting accounts impose the limits on mails/hr. How many PHPCow sites are hosted on Dedicated server? This would open up huge dissatisfaction levels as host will simply say -- Oh script is resource intensive -- and then PHPCow will have a huge list of people hurling the same statement to them and then not be ready to accept the TRUTH that for this a Dedicated server is needed. Imagine a PHPCow site with 1000 users having done News By Email. What happens to server everytime you add a news? Doing thru cron could make it eve worse .... 1000 users 20 news item added == 20,000 mails going unless it's made out to be a digest which also would mean 1000 mail/site. Shared host would be quick to suspend the account for sure.
Publish/Unpublish is there. You can Hide articles even after publishing. Rest is possible depending upon how you play with your blocks.
User Prefix with date: Use the Date function : Prefix to get what you want.
Support: I guess the major area where PHPCow needs to think is starting PAID commercial support like many vendors (Including big guns like Oracle, bitrix and others) do. Offer PAID support on per instance basis.
I don't have a problem with paid support.....as long as the documentation is much better than it currently is. Seriously, i think you don't understand how things really work.........like about the whole server issue......I can understand you not wanting to help people, thats your business.....but PHPCOW sold their program before they got into the server business.....and as such they have an obligation to people that paid for the program.
Along the same thought process, PHPCOW is encrypted, so its not like you can pick things apart and see how they work.....to get an understanding and make good customizations.....as such, they have an obligation to the people who have paid for the program, and supported them, to either offer far better documentation/tutorials, or make PHPCOW open source so people can make changes.....then they can charge for support.... I think that PHPCOW needs to look at this.....
Yes I honestly feel they should have a PAID support in place for whatever things that they feel they can handle. x-cart charges 20-30 points just for answering questions on their members/ticket area (30 points == ~$15) for all tech support questions but that's worth it for those who want such support to get it up and moving fast. To get over this server+script issue very recently they also started offering hosting+dedicated server with their price for shared hosting being as high as $139/Mo. Normally this has become more of a practice now with most script developers. They are moving into offering hosting+severs wherever they can/have the resources to do so.
"To get over this server+script issue very recently they also started offering hosting+dedicated server with their price for shared hosting being as high as $139/Mo."
To me, thats unethical........you sell a product as a stand alone....then a couple years later decide to offer web hosting.......if thats the case, keep the products separate....because by doing it this way, they are opening the possibility of people claiming they are creating the issue just to get people to use their hosting at a high cost.......which might be fine for people just starting out.....but for people that have 2-3 years invested in PHPCOW.....to basically tell them they have to buy PHPCOW hosting, or not get help or support is almost criminal.
Costs/Pricing is just a buyer's perception. Some want to do away with any Server+Script issue so take that route although the hosting could look expensive but it really depends on priorities.
I guess i told you about gossamer-threads in some other post. They sell even more expensive hosting. They would refuse to tell how to setup a proxied mod_perl server with mod_gzip. Then we burnt few months analyzing everything and found that the mod_gzip had a bug (with no patch from developer) which prevented us from doing so and we then posted on gossamer forums :
http://www.gossamer-threads.com/perl/gfo...rl;#272058
and only then did they come up with a open answer.
http://www.gossamer-threads.com/perl/gfo..._collapsed
Till then if anyone talked of proxied mod_perl with mod_gzip on front end they just said host with them. Yes as you rightly said, it's frustrating at times but unfortunately there's no short cuts .... either outsource or DYI.
Recently we had this issue of two identical servers both running single PHPCow sites and still server with lower traffic was having much higher loads. On first contact DC said the usual stuff ... script taking more resource. Then we went back to them giving all details of MySQL QPS, http traffic details, hourly in/Out traffic etc etc. Ultimately a kernel recompile fixed everything.
I am just sharing all this so that you know ... most of the time it's server and in fewer cases it is script indeed. I can share this info as we can compare multiple dedicated machines each running single PHPCow sites so could prove what we had to say.
I know some part of this post may look as hijacking the thread but it's just a sharing of experience.