teppo

That pretty much sums up how it works with most (if not all) GitHub projects and ProcessWire is no different in this aspect. It's a good idea (even necessity for a large project like PW) to have dev branch for new and possibly unstable features.. although, as we all know, when it comes to producing code of superb quality Ryan is a true ninja

Regarding Process Export Profile diogo mentioned above, does anyone have experience about how well it works with large sites? I myself have seen that it works well with your typical site installation, but what if there are (at least) multiple gigabytes of data (assets) etc?

Just out of interest, Ryan: I'm guessing that these logos are free to use for pretty much anything we can think of (without limitations), is that right? Most likely I'm being too conservative here, but some kind of license info would be nice addition (As a sidenote, I'm actually thinking about ordering some ProcessWire t-shirts..)

Sorry, can't really answer your first question, haven't seen a setup that huge so far. So far large sites have worked pretty nicely (talking about <100,000 pages here) with the exception of repeaters causing trouble here and there. I've heard that there are some really nice speed improvements coming regarding those, though -- but I'd still generally encourage you to avoid them when building this kind of site (unless someone can prove me wrong on this one.. ) Anyway, first of all I'd suggest you to take a good look at ways to maximize site speed without applying any complicated tricks -- cutting HTTP queries to minimum, compressing CSS, JS and images, using cache as effectively as possible etc. Also: if you need to host your music videos yourself (though hosting at YouTube or similar service would generally be a much better solution) I'd create an external server just for static content like that; "videos.example.com" or something like that. All the big guys are doing stuff like this already. Regarding splitting PW site on two (or more) servers, that should be possible in theory, but would require a lot of work and could be a little "hacky." The main problem here would probably be assets; you could have multiple servers running PW while still sharing one database server (and a load balancer in front of those servers) but you'd need to find a way to keep assets synchronized. I don't really have a viable solution for that at the moment, though it's something I've been looking into too -- currently handling stuff like that with rsync, but that's nowhere close to "real-time." I think someone somewhere (?) mentioned that PW sessions can also be saved in database, which would help a bit here - don't know if that feature is still in dev branch though. Another solution would be to run a main site on one server + separate "subsites" on others (example.com, genre.example.com, anothergenre.example.com, users.example.com, auth.example.com, comments.example.com etc.) but that'd make communication, searches etc. between those sites way more complicated and at least require some kind of SSO solution. To be honest quite often it just makes sense to keep things running on one server (with the possibility of separate servers for database + static files as mentioned above) and when requests pile up just put some extra muscle on those servers. That's another reason to love virtualization.. keeps things nice and flexible Edit: the more I think about this, the more I start thinking that the viability of having one PW site run on multiple servers simultaneously is related to how often assets are added / changed / removed. If your typical user doesn't have the right to manage assets, it would be relatively simple to implement a server-side watcher that would sync assets between sites / servers. Rsync (for an example) has an option to only sync files that have been added / changed, thus you wouldn't have the need to sync all the files between servers whenever something is changed. In this setup cache files could cause some trouble, though -- not sure how to handle those properly. A filesystem watcher could be a self-made server-side combination of rsync + cron (non-realtime) or some of the already available applications, such as Lsyncd. Quite possibly you could also have the watcher work as a PW module, hooking into file save operation and then invoking rsync / other sync method via exec() -- not sure if there's an easy place to hook into yet though, just throwing in some random ideas here. Oh, and all of these ideas rely heavily on you having complete control over your servers. I hope that's the case. They're also based on my relatively low knowledge of PW + server administration, so there might be a much better solution available..

So, basically you want to render a form with exactly the markup that Twitter Bootstrap requires, right? If that's the case, then I would imagine your only chance (right now) being looping through fields and generating markup on the fly yourself. There's no shortcut for this one, I'm afraid. Depending on your form and how static it is, this might be an easy task or a very difficult one. If you're only having to deal with text inputs and textareas, it shouldn't require too much work - but supporting all possible fields (especially images, files etc.) would be a real pain. Try to keep things as simple as possible

If I understood correctly what you're after, you should check out Form Template Processor (http://modules.proce...late-processor/.) That module does pretty much exactly what you've described above. Edit: After re-reading your post, I'm afraid that Form Template Processor might also be somewhat overkill for your needs. I'd still recommend to check it out, but in case that you simply want markup for inputs, you could probably foreach through $template->fields() and for each field you want displayed call $field->render(). That approach would require quite a bit more work than simply using Form Template Processor or something similar, but if that's definitely what you want then it's one possibility.

You could take a look at the blog profile, http://modules.proce...s/blog-profile/. Only problem here is that it currently cannot be easily installed on an existing site, but if you're only starting (it's a new site) then that should do the trick. If it's an existing site, you could still take a look at included features under "Blog Profile Features" heading on that page to get a pretty good idea about what kind of things to keep in mind when building your own blog. If you're working on an existing PW site and wish to build custom blog, easiest method would doing exactly what you mentioned above; creating templates for "blog home" (unless posts are direct children of your home page) and blog posts + adding the comments module for blog post template. After that you'll just start adding pages with blog post template under your home / blog home. That should get you started, though things like RSS feeds (see http://modules.proce...les/markup-rss/), lists of new / popular / most commented posts on home page etc. are commonly used features on a blog site and not that hard to build at template level.

Did ProcessWire install succesfully anyway or was there a problem (in addition to it complaining about mod_rewrite and server software?) There have been at least two mentions of PW being installed on LiteSpeed here at the forum and in those cases everything seemed to work. You can view discussion about this topic and related tests here: http://processwire.com/talk/topic/1212-processwire-on-litespeed-web-server/. If install goes smoothly and everything seems to work (see tests at aforementioned thread), there's probably no reason to worry -- it's only natural that PW complains a bit about these when it's not installed on standard Apache configuration

That's good to hear, thanks Ryan!

@digitex, update hasn't been pushed to GitHub yet -- I should know, since it was my pull request that broke this before, terribly sorry for that! Just opened a pull request with a fix for this problem, just in case. If you need to make the fix locally you can review required changes here: https://github.com/ryancramerdesign/TextformatterVideoEmbed/pull/2/files

Could this be of help: http://processwire.com/talk/topic/648-storing-module-config-using-api/?

Sounds like a problem with the permissions of your /site/assets/ folder. Some solutions for related problems have been posted here: http://processwire.c...mages-or-files/, you could try those for a start.

Hello there! Without knowing exactly how your module works, I can only throw in general ideas - hope they're of some help: a) You could use a GET variable for this; example.com/example-page/?view=newsletter and then "if ($input->get->view == "newsletter") { ... }". b) There are many solutions for this one. Simple way would be fetching the content of your newsletter page ($newsletterPage = $pages->get('/page-uri-or-whatever')) and then including a file with your alternative markup (in which you use $newsletterPage instead of $page) wherever you wish to render the newsletter. Another method would be to play around with actual template files; see this post by Soma for an example. One slightly crude method to get JSON (or pretty much any other markup you need) out of a process module is to output it (echo, output buffering, whatever floats your boat) and then die() -- or exit() if you prefer it that way. There are cleaner ways to do this too, but hey -- it works

Nico, just out of curiosity: are you thinking about "just" the subscription part or a module that would actually handle the whole process from subscription (and cancellation) to building and eventually sending out a newsletter?

If what Antti said above has been taken care of at some point, this might be the problem here: $myCalendar->setIcon("$config->urls->templates_php/calendar/images/iconCalendar.png"); Try doing it this way instead: $myCalendar->setIcon("{$config->urls->templates}_php/calendar/images/iconCalendar.png"); Of course that would only work if the path for this particular icon is /site/templates/_php/calendar/images/iconCalendar.png.

@celfred, either the video you're trying to embed has embedding disabled or this could be a problem (or feature, can't really tell yet) at YouTube. There's similar problem reported at the WordPress bug tracking system here: http://core.trac.wordpress.org/ticket/14377. This example you gave returns code 401 Unauthorized and this is what oembed.com has to say about this particular error code: Will have to do some more testing later.. unless, of course, someone else knows a solution / answer to this problem already

@benbyf, are you getting any Javascript errors in your browsers developer tools console? What about Apache + PW error logs? Seems like something isn't loading / running properly, so that's where I'd start digging into this one. Also: you seem to be running quite an old version of ProcessWire; sadly I'm not very familiar with the 2.0 release and differences it has with 2.1 or 2.2, but just to make sure, you did the re-install with version 2.0 too and not a later version?

@celfred, you've got two problems in that example: YouTube links need to be alone in their own paragraphs, there shouldn't be any other content in same <p> tag -- try adding the descriptions below or above actual YT links (also: now they're in a list, which probably won't work either) Don't make them actual hyperlinks; I might remember wrong, but IMHO that way they won't work -- just plain URL as a string without the <a> tag I hope this helps a bit.

@Sevarf2: Repeaters most likely aren't what you'd like to use here. You might consider using either simple module + custom data table (Antti has a nice example of this in his Process Redirects module) or perhaps even custom field in user template (if this data is actually linked to ProcessWire users) populated with JSON -- it may sound like an odd choice but I've used it for certain simple needs and it's actually quite efficient and very simple to handle with json_encode + json_decode

Hello there, First of all, letting a client post HTML straight into a field and then echoing it (especially without escaping anything) could potentially break things up and cause quite a bit of confusion / extra work for you, so I wouldn't really suggest it. IMHO better option would be to ask the client to post WordPress embed tag offered by SoundCloud to the body field (or any other field you've specified, actually) and then replace that with actually player code at your template. WordPress embed tags look like this: [soundcloud url="http://api.soundcloud.com/tracks/59233018" iframe="true" /] Simply ask your client to post these tags to whatever field you've specified, each as it's own paragraph (just paste and hit enter when field has TinyMCE enabled.) Then include this code in your template (I'm using body field as an example here): <?php $replacement = '<iframe width="100%" height="166" scrolling="no" frameborder="no" src="http://w.soundcloud.com/player/?url=http%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F$1&show_artwork=true"></iframe>'; $page->body = preg_replace("#<p>[^\w]*\[soundcloud url=\"http:\/\/api.soundcloud.com\/tracks\/([0-9]+)?\"[\w\=\" ]* \/\]</p>#i", $replacement, $page->body); That should do the trick. EDIT: once again I've been too slow.. damnit. Oh well, now there's twice the regexp fun to check out. EDIT 2: @danielholanda, even though both answers so far have certain similarities (regexp ftw), there's actually one important difference just in case you've missed it: the method diogo provided is based on adding a specific field for songs. This way if you want multiple songs on one page you could add that field inside a repeater and loop through it's content. The method I posted above is based on the assumption that you could be using that same field for both "typical" content and (multiple) SoundCloud embeds. I'm adding this just to clarify both methods a bit and make it easier to choose which method you're going to use. This really depends on how your client will manage this content too; especially if each SoundCloud clip has it's own page there's very little point for using the latter method.

SiNNuT: what I was talking about back there was probably more like HTML prototyping than just plain wireframing, though in my humble opinion HTML prototypes are rather straightforward evolutionary step of HTML wireframes -- or "HTML wireframes on steroids." Basics and reasoning behind these kind of techniques are discussed (for an example) in this Webdesigner Depot article, this Handcrafted post about how 37signals work on their designs and in this rather old but still valid blog post by 37signals about why they like to "skip Photoshop." I'm still hoping more people in our industry would take these techniques even further though. What I'm currently most interested in (and experimenting with) is taking HTML wireframes to what I see as "the next level" by adding not only bones (wireframes / structure) but also as much meat (functionality) as possible before drawing / having someone else draw the skin (graphics) on top of it all. Yeah, I really suck at metaphors. Sorry for that. I'm actually working on a project right now that I'd love to see as close to being completed as possible before adding any distracting eye candy, though that's definitely not an easy task to achieve; lots of people still claim (I say claim because I'm not very satisfied with this answer) that they cannot really "get" the whole thing without seeing layouts. In my opinion keeping things as bare and clean as possible forces everyone to concentrate on what really matters: usability and user experience. Long story short: what you're doing is probably very close to what I'm talking about here and I'm happy to hear that you've already implemented a method like this. I'm not a big fan of front-end frameworks myself and definitely not an expert on that subject, but if I've understood properly how they work (and why they exist in the first place) this is exactly what they're good at