teppo

@netcarver: luckily there's this neat new thing called "the Internet": http://www.noupe.com/how-tos/10-ways-to-automatically-manually-backup-mysql-database.html. Periodic MySQL dump is easy to set up and enough for most cases

Should probably be ashamed to admit it, but I wasn't fully aware of how much you can do with built-in filter / sanitize functions and their various options. Lets just say that I could've avoided a lot of RegExp-related headache by checking these out more thoroughly. Many other interesting things mentioned there also -- especially in the testing and caching parts, I bet those will come in handy as reference material. Overall very nice article, so thanks for sharing this SiNNuT!

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