adrian

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.

I am sure I am missing something about what you want to do, but this works for me: $target_page = $pages->get(xxxx); $target_page->files->add("full url to file"); $target_page->of(false); $target_page->save(); I haven't looked to see what PW is using in the background (maybe file_get_content with a fallback to cURL), but there might be an issue with file_get_contents if you have allow_url_fopen off in your server config.

Just to tie this issue back to the support board for the module. This issue has been reported, starting with this post: http://processwire.com/talk/topic/421-helperfieldlinks-field-and-template-edit-shortcuts/?p=48416

Wow guys - what an amazing set of answers to this question. Glad I wasn't around and didn't try to answer this - I would have felt quite inadequate. Gotta love this community

Do you have debug set to true in your config.php? Anything showing up in assets/logs? Also check your dev console as the error might be ajax related as it grabs the page list.

Same menu issue here on Android 4.3. And testing on iOS, I see the mobile version of the menu, but it only really works at the top level. Once you tap Setup, you still don't get the option for the other menu levels, it goes straight to the setup page, but maybe that is intentional.

Not sure I completely follow, but it might be better to just send the page ID to the login form: ?pageid={$page->id} It is cleaner and easier to send a number in a "get". Then you can do: $pageid = (int) $input->get->pageid; to make sure it is only an integer that was sent to the form. Then on the page that displays the form you can get the path of the page if you need it using: $page_path = $pages->get($pageid)->path; But depending on your actual code structure and needs, there might even be a cleaner way. You could potential use a session variable - lots of options. If this idea doesn't seem a good fit, let us know and we'll help you get it better optimized.

It sounds to me like you might be running a version of jQuery that is 1.9 or greater which doesn't support .live and needs to be changed to .on

PW caches any image sizes you create with $image->size(), $image->width() or $image->height(). They are all stored in your assets folder and called directly if they already exist.

Why the "deny from all" ? Do you have something overriding that elsewhere for the site specific directories?