adrian

I just discovered this myself last week - great to have a cleaner way to present this type of logic.

Hey diogo - not sure, but I don't think that works in php <5.4 does it?

Ok, I decided to do some testing at my end on the connection issue. I was trying with a gmail account using imap and found I needed to force a secure connection: http://flourishlib.com/docs/fMailbox It seems to me like this module should have an config option to define this true/false, but for the moment I just changed this line in the .module file from: $mailbox = new fMailbox($this->emailType, $this->emailHost, $category->emailAddress, $this->emailPassword, $this->emailPort); to: $mailbox = new fMailbox($this->emailType, $this->emailHost, $category->emailAddress, $this->emailPassword, NULL, TRUE); I was having connection or username/password issues until I made this change, but now it works perfectly and pages are created as expected. Can you let me know if that works for you and if it does I'll add a config setting for it and add that to the pull request to Pete.

Glad that sorted out the category adding issue. I'll submit that pull request to Pete. As for the server connection issue - I am really not sure, but I don't think it is related to this module. Perhaps there are some issues with the Flourish library (included in this module) and your pop/imap server, or a firewall issue. Maybe someone who has been using the module more might have a better idea.

The last two RewriteBase options are just examples really. You need to enter the subdomain path and use that and it should work.

I have attached a revised version of the module. I know Pete is pretty busy with other things at the moment, so I thought I'd try to help out. I haven't tested this thoroughly, but I think it should take care of things. It also includes a few other fixes, like adding delete buttons for each category and also fixing a bunch of PHP warnings. If you could test and let me know if everything is working fine and then I'll submit a pull request for Pete. My forked version

Agreed - the logo doesn't look great for me either. An SVG version with PNG fallback would be nice. You might even make use of my rasterizer module for generating the PNGs on demand at the size needed

Nice catch horst Can I go one simpler: $pids = array(1010, 1011, 1022); if(in_array($page->id, $pids)) { echo $pages->get("1114")->body"; } or even just: if(in_array($page->id, array(1010, 1011, 1022))) echo $pages->get("1114")->body";

Hey kongondo - no worries. Maybe it will be ready for the modules directory sometime soon. I just need to find the time to get back to it - maybe this post will get me motivated to find the time - I do think it has lots of potential and most of the hard work is already done

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(); }