adrian

Turns out the issue with the site map page is not due to the rewriting of links and is actually an issue if you try to render that page from another page, completely independent of this module. I am using render() when the "Load" option is selected, hence the problem. I will still see if I can find a way around this, but for the moment I have set the load option to ignore the site-map page (instead, it defaults to redirect). I have pushed this latest version with the custom URL rewrite option to Github and updated the modules directory. Let me know how it goes for you.

Is this any help: http://modules.processwire.com/modules/custom-page-roles/

You could try Nico's new Wordpress Migrator module: https://processwire.com/talk/topic/4420-page-list-migrator/?p=62349 https://github.com/NicoKnoll/MigratorWordpress I would thoroughly recommend trying first on a test PW install to make sure everything works as you expect.

Well I have a version for you to test. It has a new option called: Rewrite Links and a companion "Rewrite Format" in the config settings. This way you can determine how the urls will be rewritten. I have tested with: /{$page->name}-{$page->id}/ and /{$page->id}/ I attached this version here as I don't want to push it to Github yet. It mostly seems to be working fine, but there is a problem when loading the default PW sitemap page. The recursive function for generating the page links is causing some major problems, so please don't try that. Let me know if you think this approach meets your needs though and I'll figure out how to fix the bug and maybe consider a more efficient way to do things - I never planned this module to have this functionality, so there might be a better approach. EDIT: Please keep in mind that I mostly agree with Pete - long friendly URLS are a much better default. I think the name-id combo isn't a bad idea because it creates a permanent link even if the page name changes, but the id on its own seems like a bad idea for a default URL. The module's original goal was just to allow for shortlink alternatives, but not replacing the default link.

Check out the RewriteBase options in the .htaccess file. My guess is that you need to uncomment the first option.

I have added a new option called "Changes since" in the export dialog. This is very basic at the moment and put together quickly, but it allows you to specify a date/time which will limit the exported json to only content that has changed since then. It's certainly not the most efficient approach in that it will export the entire page, even if just the content of one field has changed. I don't expect this should be much of an issue, but it might seem wasteful if you have a page with a lot of images or files, but you only changed one small text field, because it will copy all those images/files again. Unlike most fields, image/file fields have created/modified fields in the DB tables, so I should be able to improve this fairly easy - something for the next version

Well you might have already sorted it out, but it's hard for us to help without seeing the section of code that contains the getRandom(). This should work: echo $testimonial_image_page->images->getRandom()->url; If it doesn't and you get the same error, then please check to make sure that the template of these pages has a field called "images".

Thanks for the report - I have fixed this bug and pushed it to Github. Let me know if it works for you now. I agree with Pete about not generally wanting to have links go to ID based URLs though. My module is just meant to be an easy way to provide a shorter link, or perhaps a human readable link with the ID appended, like: http://www.mysite.com/article/this-is-the-full-title-1058/

Thanks Soma, That is certainly cleaner and simpler Only thing I needed to add back in was: $f->datepicker = 3; And in case someone is wondering about the 3: https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module#L24 const datepickerNo = 0; // no datepicker const datepickerClick = 1; // datepicker on click const datepickerInline = 2; // inline datepicker, always visible (no timepicker support) const datepickerFocus = 3; // datepicker on field focus I ended up in one of those situations where I was trying to add attributes to match the generated source of a working datetime field, rather than figuring out exactly what PW needed to set them itself. Can I blame it on the fact that it was 1 am

Actually thanks to the genius of WillyC, that is pretty easy. Well I guess it's really Ryan's genius, but Willy's post has been a classic for quite some time! $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; $e->return = "/$page->id/"; } That will rewrite all your links, but you'll still need my module to make the links actually work. I am actually thinking this code might be a nice optional addition to my module. Of course you can put a conditional "if" to only return the id for particular templates or whatever if you need. EDIT: There actually appears to be a conflict between the two - stay tuned - I'll take another look at this tomorrow

I guess I don't really know exactly what you want. That module will allow you to link to any page using its ID. Are you want to have internal links in an RTE field be ID based? If that's what you want you could create a simple text formatter module to change the links. Sorry, I am probably missing your point still. Could you explain your scenario in a little more detail. I am sure there is a way to achieve what you are looking for.

Some progress. Adding: $f->attr('dateInputFormat', "Y-m-d"); $f->attr('timeInputFormat', "g:i a"); populates the time as well, but it is always 12:00 am, ignoring what is set in the value. I'll keep experimenting and report back. EDIT: Ok, I got it - you need to set the value to the unix timestamp Final code: $f = $this->modules->get("InputfieldDatetime"); $f->name = 'changes_since'; $f->label = 'Changes since'; $f->datepicker = 3; $f->attr('data-dateformat', "yy-mm-dd"); $f->attr('data-timeformat', "hh:mm:ss"); $f->attr('dateInputFormat', "Y-m-d"); $f->attr('timeInputFormat', "H:i:s"); if($form->get('changes_since')->value){ $f->attr('value', $form->get('changes_since')->value); $f->attr('data-ts', $form->get('changes_since')->value); } $f->attr('class', 'FieldtypeDatetime'); $form->add($f);

Hi everyone, I am trying to add a datetime field to a process module and am having a weird problem here. This is my code: $f = $this->modules->get("InputfieldDatetime"); $f->name = 'changes_since'; $f->label = 'Changes since'; $f->datepicker = 3; $f->attr('data-dateformat', "yy-mm-dd"); $f->attr('data-timeformat', "h:mm tt"); $f->attr('value', "2014-03-13 1:45 pm"); $f->attr('class', 'FieldtypeDatetime'); $form->add($f); When this field is displayed the value is just: 2014-03-13. For some reason the time is missing. However, when I use the datetime picker a make a selection, the field is then populated with the full date and time. Not that it helps, but if I change the field type to InputfieldText, the full date time is shown when the input renders. Also, something else weird I noticed is that when I submit the form, $input->post returns the correct date and time, but $form->processInput($this->input->post); echo date("Y-m-d g:m", $form->get('changes_since')->value); returns: "2014-03-13 12:03", no matter what time I select. I think this is to do with the am/pm in the time format. If I compare the generated classes, ids, etc for this input field vs one in the admin when editing a page, they are the same so I am currently at a loss. Thanks for any help!

The linked module above will let you do that: http://modules.processwire.com/modules/process-redirect-ids/ Works for either all pages, or specific templates/pages that you select.

Not sure exactly what you mean here - don't know whether you wish php was actually a client side language or whether you just want to be able to test your code in the browser. If by chance it is just the latter, then one of these might help: http://sandbox.onlinephpfunctions.com/ http://phptester.net/ http://writecodeonline.com/php/ http://phpfiddle.org/ Anyone feel like porting PW to nodejs

So then in your profile.php redirect you need: if(!$user->isLoggedin()) { $session->redirect('/login/?pid='.$page->id); }

Thanks Raymond, I built an email template about 10 years ago (all tables and inline styles) that I am still using and remember all about Outlook's html rendering. It actually got worse from one version to the next back then. I hadn't yet seen anything on responsive options though, so thanks for those other links too!

Not sure I understand, but if you want to redirect from your profile edit page back to the last page they were on, then the initial link to the profile page should include the ?pid= and then would want the same redirect code in your profile edit page to grab the page id and use that for the redirect. Does that make sense? Sorry, in a bit of a rush.

I don't really understand why you want it in the foreach loop. Unless you are rendering out this menu in multiple places, there is no need to have the code in the function either. Maybe that is just my take though? Curious to hear what others think.

I haven't actually read this yet, but I am intrigued, so using this as a bookmark for later http://alistapart.com/article/can-email-be-responsive

Hey Martijn, It's not you - there is something wrong with either Github or Ryan's module creation code. I guess Github changed something in their API recently? I have mentioned it to him already. In the meantime you can simply edit your module's entry in the directory and manually add in the "master" before zip.

Sorry I didn't actually look at mindplay's code. It might be easiest to just: echo '<li><a href="/">Home</a></li>'; before the spot where you return the output of the function. Perhaps if you are still confused so us your complete code so far.

Did you make sure that basic-pages was selected as an available template in the module config settings? Take a look at the screenshot here: http://modules.processwire.com/modules/service-pages/

Something like this should work: $menu_items->prepend($home); Of course this all depends on the array of pages that you are iterating through to generate your menu. And of course you need to define $home, like: $home = $pages->get("/"); Lots of options really.

madalin, PW 2.4 manages themes a little differently. Unfortunately most (all?) of the third party themes have not been updated yet. Here are some instructions on how to get it to work: https://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=53671 However honestly I think you are better off sticking with the default theme at the moment - there is a lot of new functionality in there that the old themes don't support. I also know that there is a second 2.4 specific theme just around the corner, and I am sure more will follow.