adrian

It sounds like you have given the editor edit permissions, but you might need to check the Access tab for the template in question to make sure that role has editing permission.

Check out this module: http://processwire.com/talk/topic/4420-page-list-migrator/ It is still in development, but it allows you to export a hierarchy of pages, templates and fields from one PW installation to another and import them into another PW installation. It currently doesn't copy the actually template.php files, but that is the easy part really A blog setup is definitely one of the uses I am thinking of for this module, but at the moment you will find on the import page of the module the ability to import/create the pages/templates/fields for lists of countries and a few state lists. I really do want to get back to finalizing this module, but it is in a usable state already although I would definitely recommend running it on a test installation of PW and not one with data that you care about first. If it works for your needs then use it wherever.

No problem, another alternative would be: $pids = array(1010, 1011, 1022); $downloads = $pages->get("1114"); if (in_array($page->id, $pids)){ echo "$downloads->body"; } This would be cleaner if your list of pages started getting longer.

$downloads = $pages->get("1114"); if ($page->id == '1010' || $page->id == '1011' || $page->id == '1022'){ echo "$downloads->body"; }

The key is find vs get: $downloads = $pages->find("id=1|1114|1452"); foreach($download as $p){ echo $p->body; } EDIT: Actually I am not quite sure what you are trying to achieve. I left out the check for whether the current page is id=1011, but you can easily add that back into my code. Am I on the right track with grabbing the content of pages using multiple IDs in the find, or am I off track completely with what you want?

Wow, speedy service! It shouldn't be that complicated to get imagemagick compiled with rsvg. I have certainly had my issues with dependency conflicts over the years, but two weeks is a lot of debugging time Anyway, great to hear you have it working now and the conversion results are good. I am really excited to have someone else using this. I wish there was an easier way to make these conversions, but unfortunately there is nothing simple. There are options that use batik (needs java) and some php classes that make use of running inkscape via the command line (relies on exec which is often disabled), so the imagemiagick / rsvg combo seems to be the best option and gives great results. That latest version should have fixed a few dimension calculation issues from the previous version, but please let me know if you come across any issues or have any ideas for improved functionality.

It isn't always as simple, but in the case of this module with the way that statement is structured, you can simply replace "live" with "on". If you want you can file an issue over at: https://github.com/NicoKnoll/ProcessPageDelete/issues/new and ask Nico to make the change. I don't think there is any need to worry about detecting the availability of "on" anymore with a "live" fallback, because PW is using jQuery 1.8 which supports "on".

http://modules.processwire.com/modules/service-pages/

Nice - I really like the look with the rockies photos and the geometric patterns!

Hi everyone, Another overhaul today. A few bug fixes and a bunch of new features. I have updated the first post here to detail them better, but key things are the ability to make use of the following variables in the filename format: $page, $template, $field, and $file. To accommodate some of possibilities this opens up, eg: $file->description, there is new logic to handle renaming after page save if the filename format can't be properly evaluated at upload because the field isn't available yet, or is still blank. If possible, renaming will still occur during upload - "on save" is just a fallback if needed. Another key addition is the ability to give each rule the option to rename the file again each time the page is saved. There are obvious issues with this if images or files are being linked directly by their URL, so care is needed with this option checked. It does allow for some incredible flexibility though. You could even have a field in your template called "Filename" allowing the user to rename the file whenever they want. In most scenarios of course this would not be at all desirable, but it suited my needs, so thought it might come in handy for someone else as well If nothing else, it might be useful during development, but could be disabled once the site is live. Let me know if you find any bugs with this new functionality.

Sounds like you have something weird going on with your config file regarding the duplication of DB details, but I think your 500 error might be coming from the modrewrite base setting in the .htaccess file. Some relevant posts that might help you narrow down exactly what needs changing to what: http://processwire.com/talk/topic/4434-pw-not-installing-correctly-admin-not-found/ http://processwire.com/talk/topic/4917-the-admin-cannot-be-reached-in-new-installation/

Really great diogo - fantastic looking site Also, love the meanmenu - I think that is the first mobile friendly menu I've seen with the plus for expanding submenus, thereby avoiding the need for duplicating the parent item - might be my new favourite!

I think these threads answer your question: http://processwire.com/talk/topic/4812-field-names-using-arrays/ http://processwire.com/talk/topic/691-wireinput-only-allows-one-dimensional-arrays-why/ Just use $_POST instead.

If you're mostly wanting to change the theme colors, I'd recommend you read this post: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=54479 Ryan explains how you can create a new color scheme for the default admin theme. Hope that helps.

Hi verdeandrea and welcome to PW. PW 2.4 introduces a new system for managing admin themes. If you are using 2.4 and you're new to PW I would recommend staying with the default theme for the moment until existing themes are updated to handle some of the new functionality. However if you are still keen to change, I think all you should need to do for the moment is uninstall "Default Admin Theme" from the Core tab of the module settings page. Then your manually installed theme should work. Alternatively, you could follow Ryan's instructions for converting your old theme of choice into a new installable theme: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=53671 Let us know if you need any further help.

Nice one Reno. I just tested and it works! My quick mash - I am sure it could be improved. $template = $templates->get("your-details"); foreach ($template->fields as $field) { $fieldlabel = $template->fieldgroup->getField($field, true)->label; echo "<label for='$field->name'>".$fieldlabel."</label>"; $inputfield = $field->getInputfield($page); echo $inputfield->render(); }

Does this help? http://processwire.com/talk/topic/2170-how-to-utilise-field-template-context/

Sorry, I probably wasn't very clear on that - I am talking about php scripts that need to be called from the browser, but that are not PW template files. For example this could be an AJAX call to a php file. That make sense now? To clarify, any javascript files can definitely be run from inside templates/scripts. Sorry for the confusion.

Mike, The great thing about PW is that you can structure and name files however you want and put them in whatever subfolders you want. The only real restriction is that your main template files (the ones that relate to the templates you set up in the PW admin) must be in the site/templates directory. The only other restriction is that if you want to call any scripts directly, they need to be above the sitefolder. Other than that, you can do whatever you want. Feel free to add as many include folders and name files however best suits your workflow. I haven't used Drupal so I may not be the best person to comment, and maybe you can do this is Drupal too. It's on the roadmap: http://processwire.com/about/roadmap/

Just include this in your selector: id!=1031|1032 eg: $reisen = $page->find("parent=$parents, id!=1031|1032, sort=reise_abfahrt"); Be sure to check out the selector test module from Nik - very helpful in figuring these things out: http://modules.processwire.com/modules/process-selector-test/

Ryan is pretty diligent at viewing all forum posts, but your safest bet is to file an issue over at the GitHub repository: https://github.com/ryancramerdesign/ProcessWire/issues

What about using $image->width and $image->height to get the size of the image. Although I am not sure if you are defining this in the template already anyway, or if you are grabbing it from the original uploaded image. Anyway, thought it might be of some help.

Hi cork and welcome to PW. I believe all you need to do is this: $body .= $page->comments->renderForm(); The $body variable is built with the various pieces of content that you want to show in the template and is echo'd here in the _main.php file: https://github.com/ryancramerdesign/FoundationSiteProfile/blob/master/templates/_main.php#L113 Or if you want to keep things clearer you could do: $comments = $page->comments->renderForm(); and then echo $comments somewhere else in the _main.php file. So much flexibility in PW which can be daunting initially, but you'll come to love it very quickly Let us know how that goes for you.

I am getting the same behaviour. Probably obvious, but a simple fix until Ryan takes care of it, is to set the default view to rows. That way if there is only one image, they can't get it into grid view in the first place.

Have you read the pages on repeaters, especially the section on: "Finding pages by repeater value (using selectors)" You should be able to figure it out from there using a selector that finds items with schedule_date > time() Let us know if that gets you on your way, or if you need more specific help.