teppo

Hello there, and welcome to the forum! What you're describing there sounds like something PW handles very well. You could, for an example, create all those sections as pages in PW and have one template file render content for all the others. Here's a post about somewhat similar concept: http://processwire.com/talk/topic/821-question-understanding-templates%E2%80%93advanced-templating/#entry6999. This way you'd create a template file for all individual sections (assuming that they actually have different markup & fields each) and then at some point, index / home page probably, render them all. Please note that I haven't done anything like this myself, but the concept doesn't seem too difficult - I'm sure others will be able to provide more helpful examples and educate us both about more sophisticated ways for achieving this result. ... actually, this sounds like a good idea for a nice little tutorial if anyone has some extra time ...

Sounds great! Makes sense. In my case this problem appeared after importing pages with ImportPagesCSV module..

Is there any way to insert file / image descriptions while importing? If not, any idea how one could implement a feature like that?

Couldn't find another topic on this, so I'm creating a new one. My idea (wish, if you wish.. no pun intended) is actually quite simple: wouldn't it make sense to enable sort order setting for templates in addition to individual pages? That way I wouldn't have to re-set sort order every time I create, for an example, a news page (which can only contain news items and thus has pretty much only one usable sort order throughout the site.) Also: current default sort value for new pages is "none", which can produce quite peculiar effects - apparently because DB itself uses some very obscure magic for deciding sort order - and I'm having hard time figuring out why anyone would wish it to act like this. As a second idea, wouldn't it be nice if default sort order was "created" instead of "none"? So - what do other folks think about these? Oh, and by the way, if there already IS a way to achieve one (or both) or ideas above, that'd be great (and in that case, sorry for the confusion!)

Antti: regarding the form builder, you might also want to check out how this stuff is handled in Form Builder Plugin for Pimcore: http://www.pimcore.org/wiki/display/PLUGINS/Form+builder+plugin. Pimcore uses Ext JS heavily for all it's views but putting that aside the basic UI concept there doesn't seem too far from what would be required here.

Thanks netcarver - had a quick look at those and it does look promising already! Please, keep up the good work -- and make this available for us "outsiders" as soon as you feel it's mature enough for that Somewhat offtopic: what you're building there kinda reminds me of Zend_Form and actually made me think about putting up a quick proof-of-concept of using that in a PW site. If not for production use, might at least be interesting to see how (and if) it works out.

So the only thing that's not working is changing the link (and link content), right? If that's the case and you only have two languages, something as simple as this should do the trick: <?php $lang = ( $user->language->name == "finnish" ) ? "default" : "finnish"; echo "<a href='./?language={$lang}'>{$lang} flag</a>";

It's obvious that stuff like this takes time -- and building multiple features, especially when they're big ones, at same time is nowhere close to a good idea -- but I just had to drop in to say that we're really, really looking forward to the form builder too. Anyway, it's always good to get a heads up about how things are going, so thanks for sharing this Ryan! I'll go check what Netcarver's been building now

Sorry, completely missed your other question, about most popular pages. I don't recall PW having anything like that built-in, but you could always build something of your own; every page load increase hit counter or something like that - although that seems a bit hacky to say the least. If you need more sophisticated solution, you could always integrate with Google Analytics or some kind of Apache log parser, adding relevant statistic data to pages on a daily (nightly?) basis.

You can find a list of built-in page fields here: http://processwire.com/api/variables/page/. As you can see, "date" is not among them. What you seem to want here is "created." If you need the value of that field to be easily editable later, you could also create your own date field and apply some magic to that -- check "Default to today's date", hide field and show when needed / show always and handle pages with date value cleared somehow etc. Hope this helps!

How 'bout help.processwire.com or docs.processwire.com? Anyway, from those options above guide.processwire.com gets +1 from me.

Very good points there, Ryan - kinda guessed that there might be that kind of reasoning behind this, just wanted to make sure. I consider security very important and I'm well aware of various risks of sharing a database between multiple apps so I can absolutely respect this Developers of WP on the other hand clearly wan't to appear as user friendly as possible - even to the point where that actually works against especially their less-informed users - and this way increase the user base of WP. Personally I don't see that as such a great way to go in the long run, but I guess both ways do have their strong points. This too depends on the audience you're trying to reach and image you're trying to achieve. ... and by the way, that friend of mine already switched his web host. So the original problem has been solved

Great ideas here, but I'm still voting for putting up wiki site as a starting point. Developing something more sophisticated later on won't be much of a problem, but IMHO what we need now is first version - and we need it pretty quick, so that we can see how it starts gaining momentum. When discussing the platform choices, keep in mind that most wiki platforms are exceptionally good at handling stuff like multiple editors, access restrictions and revision history - absolute necessities if we're going to have more people producing content. My experience comes mostly from MediaWiki, though, so that's what I'd suggest. It's ugly and kinda bloated but it does get things done @charliez, that sounds great too, but wouldn't it provide some extra credibility if wiki site was running at manual.processwire.com or something similar? Though I'm not sure if this was what Ryan had in mind..

This is a great idea, folks! Of course there are various problems to solve (like has already been said - custom templates, not being too specific etc.) but most PW sites still have a whole lot of stuff in common We've been planning to build something like this for our clients, and most likely still will, considering that most of them speak Finnish (and not providing any kind of guide in their own language is hardly an option.) Anyway -- a wiki would be nice way to deal with this considering collaboration, translations and everything. I'd definitely be interested in participating in creating the material.

Thanks for the clarification, Ryan! I didn't realize shared hosting had so many underlying problems (and thankfully I don't have to deal with those when it comes to client projects..)

Glad to hear that helped! Chmod 777 can be a security risk, depending on your host and it's configuration (especially if it's a shared host), because that basically allows all users to write and execute stuff from this particular folder. I'd suggest at least setting it to something like 750 and changing owner of the folder to whatever user your scripts are executed as (chown.) If you're unsure which user that would be, this is one way to find that out: http://www.davidmorison.com/node/23. .. and if someone reading this has more knowledge about this subject, please share! I'm definitely not a Linux guru, just trying to follow the principle of least privilege combined with some common sense here

Sounds strange. I'd start by checking that ownership of and (write) access to /site/assets/ (and especially /site/assets/sessions/) are defined correctly; naturally these shouldn't just change overnight, but it's still possible that there's something strange going on at the server. Setting chmod of /site/assets/sessions/ to 777 should confirm whether this is the cause - though I definitely wouldn't suggest leaving it like that for any longer than absolutely necessary.. Also: is PW writing anything into it's own error log (/site/assets/errors.txt)?

Background story: I'm installing PW for a friend to evaluate in a web hosting platform that only allows one database. That single database already contains quite a few tables for various other systems (and to be honest names of PW tables are not THAT unique, already had a table called "pages" there for an example.) So my question is: is it already possible to prefix PW tables with something like "pw_", "mysecondpwsite_" etc? -- As a sidenote, WordPress installer for an example allows user to easily choose which prefix (if any) he/she want's to use. Makes running multiple WP installations in one DB very easy. This may not be the best solution considering security issues etc. but it's still a very real scenario for quite a few users.

Soma: my modifications (especially the latter one) could prove out to be problematic in real world use - to be honest they were originally just something created as a temporary solution for a temporary problem, but I thought I'd share them anyway in case someone else happened to like 'em Only thing I've changed is ModulesSectionCollapse.js, but since I've never used GitHub before (...) I created an account and a fork of the original project anyway. If someone wants to try out these changes, you could just download the .js file and merge changes / replace original with it. Here's a direct link: https://github.com/TeppoKoivula/ModulesSectionCollapse/blob/master/ModulesSectionCollapse.js

Just wanted to say that this module is great - I really prefer the simplicity it brings. Things like these can make a big difference in UX! Although, I must confess that I'm still using a slightly modified version with some extra information (installed modules vs. uninstalled, names of uninstalled modules on hover) visible. Added a screenshot as an attachment