adrian

Hey Marty, If they're not logged in, then I think the only reliable option will be cookies. You just need to store the ID of the PW page that stores the property's details. You could store these in one cookie as a comma separated list. I have done this with an an image library application so that guest users can create a lightbox of images. You could get a little fancier and allow them to create more than one group of properties too. Let me know if that helps, or if you'd like I can grab some non-PW bits of code as examples of how to store and retrieve the IDs. I am sure you know this, but remember that you can use both PHP and JS to manipulate cookies, so you can save changes to their list of properties without needing a page refresh. Just make sure the expiry of the cookie is set to a year or something like that. Hope that provides a starting point.

Aren't cookies the best option for this? I know you guys know this already, but surely IP address is more problematic in that it can prevent other people on the same network from voting. And even people using the same ISP may not be able to vote if they end up with an IP that is already recorded. What about a combination of cookie and number of hits from the same IP address in a certain timeframe to prevent people from clearing their cookies and voting multiple times in a short time period. I would think this would also help to limit bot rating?

Hi Emmanuel and welcome to PW. PW does not control the frontend code at all, you have complete flexibility to write the output exactly as you need, including the adding of form labels. As an example, there are different ways to do this, but if you are using PW's built-in method for generating forms, you can do something like: $f->name = "myField"; $form->label = __("Field Title"); Obviously you need to build the other elements of the form, but you get the idea. You can of course use normal HTML: <label for="myField">Field Title</label> The advantage to the first approach is that the label can be made translatable using PW's language support. You can use Bootstrap, or any other framework you wish. Ryan has recently developed a Zurb Foundation profile for PW, but it is not too difficult to use any of the other frameworks. http://modules.processwire.com/modules/foundation-site-profile/ http://processwire.com/talk/topic/2411-bootwire-basic-twitter-bootstrap-profile/ http://processwire.com/talk/topic/3832-release-unsemantic-site-profile/ PW supports multilanguage: http://processwire.com/api/multi-language-support/ You can always access the database directly. It is a standard MySQL database so you can view it easily with something like PHPMyAdmin. You can also of course query it directly using SQL statements, but in most cases using PW's API and selectors is much easier. Hope that helps get you on your way to CMS nirvana

This looks fantastic Jonathan. I know that Ryan was planning on releasing something along these lines, based on the recommend button in the modules directory: http://processwire.com/talk/topic/4206-thinking-about-a-likerecommend-button-module/?p=41222 I am curious to see what overlap there is between these two modules - hopefully they will both have their strengths and will be useful for different scenarios. Thanks for this!

If I understand you correctly, this sounds like a job for Hanna Code: http://mods.pw/4b

Thanks for the fix Ryan - that error was popping up while developing a module!

But of a rush, so not sure if this is actually related to your problem, but take a look here: http://processwire.com/talk/topic/957-how-to-find-elements-with-empty-field/ Does your selector work without the additional attempt to get a null/empty value?

Take a look at this post: http://processwire.com/talk/topic/4339-directory-creation-install-errors-when-restarting-install/ You might find that your site is actually installed properly Try ignoring those errors, enter your admin account info and proceed and let us know how you go.

Well chances are that you don't have an images field in that template - that is why it can't find the first() image from it. That code won't be a complete drop-in example for you. I don't imagine you need the entire <div class="portfolio-image-holder"> xxxx </div> section. Start by removing that and see what you get.

How rude of me - I point to your post as a reason for this thread and then forget to mention your module

I thought I'd start this thread so we could all share our favorite debugging techniques. The idea for this came from this post by Soma: http://processwire.com/talk/topic/4416-delete-user-when-page-is-deleted/?p=43320 and some of the followups with other suggestions. Here's one that I find really useful. It allows you to output content to the browser's console from PHP. It sends content from PHP through javasacript's console.log(); Not as powerful as FirePHP etc, but simple and easy to use. Put this function somewhere that it will be available to all your template files. function debug ($data) { echo "<script>\r\n//<![CDATA[\r\nif(!console){var console={log:function(){}}}"; $output = explode("\n", print_r($data, true)); foreach ($output as $line) { if (trim($line)) { $line = addslashes($line); echo "console.log(\"{$line}\");"; } } echo "\r\n//]]>\r\n</script>"; } Then you can simply put these anywhere in your templates: debug('test'); debug($variable); debug($array); This keeps your page content clear of debug messages and is easier then looking in log files, like if you were to use error_log() What are your favorite techniques?

It doesn't really help you, but this is the culprit line: https://github.com/ryancramerdesign/ProcessWire/blob/a8024bb49785370aa2e3867bd683094663cfeabf/wire/core/Pagefiles.php#L264 Ryan may consider adding @ to the list of allowed characters. I don't think there are any reasons why it needs to be removed. I think historically it wasn't allowed in filenames, but now should be fine. Some more reading: http://en.wikipedia.org/wiki/Filename#Comparison%5Fof%5Ffile%5Fname%5Flimitations http://superuser.com/questions/358855/what-characters-are-safe-in-cross-platform-file-names-for-linux-windows-and-os

Firstly, you need to make the name of the checkbox field an array by appending [] echo "<input type='checkbox' name='type[]' value='{$t->id}'>{$t->title}<br>"; Then take a look at Ryan's example: http://processwire.com/talk/topic/3061-how-to-save-field-page-type-checkbox/?p=30229

Thanks for the feedback on that - sounds like you have a better solution anyways! In case you, or anyone else misses the note in the edited first post, it is now available from the modules directory: http://mods.pw/5R Thanks again Martijn for all your help testing this - much appreciated!

Hey Nic, Just playing around with multi-language fields for the first time and noticed that if I set the Title field to "PageTitleLanguage", then the titles for all the results in the tree are [object Object] Thanks

I don't think there is any way to set a page status locked to hidden without also preventing editing, either by user access permissions, or the locked status option. However, it is easy to prevent the pages of a template from being displayed in your menu. If you are using Soma's Markup Simple Navigation module: $treeMenu = $modules->get("MarkupSimpleNavigation"); echo $treeMenu->render(array("selector" => "template!=category-site)); If you are rolling your own menu, then you can still use the template!=category-site in your selector which populates the page array for your menu. Hope that helps. If you need a more specific example, show us the code you are using and we'll show you what needs to be done.

Hey guys, I have been playing around trying to better understand multi-language stuff and it seems to me that along with the module translation that I just set up, it would also make sense to be able to automatically fill in the alternate language(s) for the fields of the sub-pages - in my example, the values for: Title, Number of Beds, Number of People, Kitchen Facilities. So, if you had three languages installed you'd be given three "Select Options" fields, one for each language. Based on my standard example, you'd fill out something like this: English Title, Number of Beds, Number of People, Kitchen Facilities Single, 1, 1, Fridge Only Double, 2, 2, Fridge Only Suite, 3, 6, Full Kitchen Dutch Titel, aantal bedden, aantal personen, ingerichte keuken Alleenstaand, 1, 1, Koelkast Alleen Dubbel, 2, 2, Alleen Koelkast Vervolg, 3, 6, volledige keuken German Titel, Anzahl der Betten, Anzahl von Menschen, Küchen Einzel, 1, 1, Kühlschrank Nur Doppel, 2, 2, Kühlschrank Nur Weiterführung, 3, 6, komplett ausgestattete Küche Would this be useful, or is this not how you guys handle things for the content pages for a Page field. PS Excuse the dodgy google translations - no offense intended

If you are converting from WP to PW you should look at Ryan's case study here: http://processwire.com/talk/topic/3987-cmscritic-development-case-study/

OK, v7 now has translations support! Wanze - thanks for the translation info. I had just finished when your message came through. Everything seems to be working fine. Maybe you could take a look for me and let me know if I need to change any of them. One other question for you guys - wasn't quite sure the best way to handle multiline description fields. In the case of the "Select Options" field, I think I may have made the translation more complicated than it really needs to be. Perhaps it would be better to put all in one translatable field and require the translator to include these as required. Trouble is that the title and description on the translation page don't get formatted, so it is hard to see what the intended layout actually is. Do you have any advice? Anything I missed?

Ok, now I understand - I wasn't thinking about making the module's form translatable. I thought you meant having the option for creating the selectable child pages have multi-language fields. Thanks a lot for the detailed example - I'll take care of it now and hopefully you can let me know if I have missed anything. Should/can the name of the module itself be translatable?

Hey, no worries - I was going to be working on another new module today, but may as well get this one perfected first What exactly do you think it needs and how do you see it working? I have played around with multi languages in PW a little, but since I don't really have a need, I am still not terribly literate with it yet. Am I correct in assuming that you wouldn't really need multi-language versions of the title of the Parent page? I am thinking you'd only need them for all fields of the child pages? So, would having separate "Select Options" textarea fields for each installed language cover everything needed? It would be great if you could detail out how you think it would work best so I don't go down a confusing path! Sorry for being an ignorant English speaker PS Go grab v6 from Github - some restructuring of the form - layout and instructions, fixing of a bug if the field already existed, and more friendly error reporting in general.

Good point - v4 is now available and includes a list of available text fields that can be used instead of automatically creating new ones if appropriate.

Just a heads up that in the modules directory, this has two authors listed: martijn and geerts. Would be nice to have that corrected so it is together with all your other modules under: http://modules.processwire.com/authors/martijn-geerts/

Glad to hear it's working again! I don't mind moving the examples for the Select Options field to the desc, but I am actually not sure what you mean by: "echo out all compatible text based fields" Do you mean all existing text fields from the entire site? I am not sure what would make them compatible or not. Remember that any new specified fields are created on the fly and added to the child template's fieldgroup - there is no need to have those fields already defined. Sorry, I think I am just not understanding what you mean