ryan

I like the idea of this, but one potential issue: not all URLs begin with 'www'. For instance, you can't access processwire.com from www.processwire.com (it'll redirect you). So the proper way to link processwire.com is just http://processwire.com. Another example would be http://store.di.net, which is something different from www.di.net. I think what would be better is to have it auto-link URLs that start with a http:// or https:// on the front. That way there's not much chance of it autolinking things that it shouldn't. The regex would have to check that the http:// doesn't have a quote or equals sign in front of it (indicating an already-linked URL). This could be done by checking to make sure the http:// is either at the beginning of the source string (no characters preceding http://) or the preceding character is [^\w"\'] meaning not a word character, a double quote, a single quote, or an equals sign. I think that could be placed in a lookbehind to avoid including the preceding character in the match. http://www.regular-expressions.info/lookaround.html -- edit: looks like the forum has troubles with it's URL matching

Thanks, looks like it's just the startLabel ('Add') that should be translatable, as it should pull the cancel label from the translation the InputfieldPageListSelect module -- I will fix this, as well as make the startLabel translatable in the dev branch.

Thanks, I will add this to the core!

You should be able to manually manipulate the ID. But there will be some loops to jump through with certain fields that may require manual intervention (page references, file fields, repeaters)… and this is where things get tricky. So I think you are better off copying data back to the original page rather than deleting the original and changing the ID of the clone. There will still be challenges, but I think it's the safer bet (though not really 100% certain). Regarding the repeater fields, I'm not really sure how to approach this one yet. I would be inclined to skip over repeater fields when it comes to this feature, for the short term. This is a big question and I think we can answer it, but it's going to take some time and research.

I think we might need more description. Are you referring to the blog profile? Can you tell more about the specific context of the question?

For the other part of it, in preventing the duplicates. As mentioned before, the pages you retrieve are already going to be unique. But like you said, you may have duplicate field values even among unique pages. Lets say that you wanted to guarantee the uniqueness of a 'title' field, for example: $uniqueResults = array(); foreach($results as $resultPage) { $uniqueResults[$resultPage->title] = $resultPage; } Following that, there will be no pages with duplicate titles in your $uniqueResults array. You can take the same approach with any other field(s). Though make sure your field resolves to a string before using it as a key in your $uniqueResults array.

Passwords are in a table called field_password. They are hashed and salted, and not reversible, so no way to set or change them without going directly through the API.

Check that output formatting is enabled for $user. Add $user->of(true); to the top of Soma's example and see if it makes any difference?

All of the markup and classes can be specified from the $options to MarkupPagerNav's render() method. Originally I had the Blog profile using Zurb Foundation and so had it outputting in Foundation-specific markup/classes for pagination. Doing the same thing with Bootstrap is certainly possible and should be relatively simple. Take a look in /site/templates/blog.inc and find the renderPosts() function. At the bottom of that function is this line: if($posts->getLimit() < $posts->getTotal()) $out .= $posts->renderPager(); You'd want to change it to specify an $options array to the renderPager() function, like this: $options = array( 'listMarkup' => "<ul class='MarkupPagerNav'>{out}</ul>", 'itemMarkup' => "<li class='{class}'>{out}</li>", 'linkMarkup' => "<a href='{url}'><span>{out}</span></a>", 'currentItemClass' => 'MarkupPagerNavOn' ); if($posts->getLimit() < $posts->getTotal()) $out .= $posts->renderPager($options); Change the markup and class names as you see fit. There are many other things you can specify in this options array (I've just included a few examples above). For a full list of options you can specify, see the $options array present near the top of this file: /wire/modules/Markup/MarkupPagerNav/MarkupPagerNav.module

There isn't an easy way to do that, but you can easily setup your alias from your .htaccess file. For instance, say that you wanted this URL: /site/assets/files/123/somefile.jpg to be accessible at this URL: /123/somefile.jpg You could do that with this rewrite rule, placed in your .htaccess file right after the "RewriteEngine On" line: RewriteRule ^([0-9]+/.*)$ /site/assets/files/$1 [L,QSA]

The TextformatterVideoEmbed module has been updated to support responsive embed codes. To enable, grab the latest version (v1.0.4) go to the module configuration screen and check the responsive box. Now when your videos are embedded, they will be output in a width-flexible format that adjusts to the container.

That sounds fine to me. But just send the usage for me to see it in context once you've got it.

Page::rootParent has been made hookable (now in the dev branch)

This is exactly correct. Lets say you've got this page /user-profile/ in your site. You also have a template called user-profile, and it has URL segments enabled. In the code, all you need to authenticate is to compare $user->name to $input->urlSegment1. Meaning if user 'onjegolders' accessed the URL: /user-profile/onjegolders then you would allow them to make changes to their profile. if(!$user->isGuest() && $user->name === $input->urlSegment1) { // user is authenticated and may change their password if($input->post->submit_pass) { if($input->post->pass !== $input->post->pass_confirm) { echo "<h2>Passwords do not match!</h2>"; } else if(strlen($input->post->pass) < 6) { // if you want to enforce a minimum password length (recommended) echo "<h2>Your password is too short. Must be 6 characters or more.</h2>"; } else { $user->of(false); $user->pass = $input->post->pass; $user->save(); $user->of(true); echo "<h2>Your password has been changed</h2>"; } } echo "<form action='{$page->url}{$user->name}' method='post'>"; echo "<p><label for='pass'>Change your password</label>"; echo "<input type='password' name='pass' /> "; echo "Confirm: <input type='password' name='pass_confirm' /></p> "; echo "<input type='submit' name='submit_pass' />"; echo "</form>"; } The above was just written in the browser so may need tweaks.

Technically the pageName sanitizer isn't actually necessary here (as PW wouldn't even get the request if the pagename wasn't in the right format), but it is a best practice to sanitize anything you are planning on putting in a selector. So I would do it the same way as apeisa and sanitize with pageName, even if it's not technically required.

Wow this needs to be made into an admin theme. I really like the look of this!

I think this sounds very useful, nice job with this. The solution to not having your draft pages show up in menu listings/searches is just to make use of the "hidden" status, already built into every page: $page->addStatus(Page::statusHidden); $page->save(); Once a Page has hidden status, it won't show up in any multi-page retrieval functions unless you specify "include=hidden" or "include=all" in the selector. Tested out here and seems to work very well! Thanks for your work with this module. Wouldn't it be great if it would replace the original page once you published/unhid it? (and also deleted the draft). That would bring some great workflow potential... something I can see using all the time actually. But it would have to retain the id and name of the original page, so it would be more like moving the data to the existing page than actually replacing the existing page. If you are interested in doing this, let me know what I can do to help. Some other suggestions I have: - Use an integer for your version number. To reproduce the version number you have, you'd just use 10 rather than the string "0.1". - I think it might be nice to make the PageList label just "draft" rather than "create draft", so it ties in better with the others. Also would be nice to make any of your text translatable like "draft" and "(DRAFT)". You can do this just by doing $this->_('draft'); rather than 'draft'. - If a page is already a draft, it might be nice if it doesn't have the "create draft" option.

The "../../../../" looks odd to me, as you shouldn't see that kind of relative path in any ProcessWire $config->paths variables. What is the directory setup? Are there symlinks involved? Another odd thing here is that this error comes from /wire/core/TemplateFile.php, meaning something is trying to render the user.php template (which of course, does not exist in any PW install unless you add it yourself). My best guess would be that there is another module involved here that is trying to render a page, as there's nothing in the core that would be trying to render a page when you save a user (at least, nothing I can think of).

This is great, thanks for posting this.

I should mention that this blog profile is just one approach to ProcessWire templates. This one was intentionally made to explore an entirely different path than what is used in the default profile. The approach is probably different from what you'd see in most ProcessWire sites, but I think it's a good approach for long term scalability, especially when the front-end and back-end development are handled by different people. Though there are also other equally good approaches too. In the blog profile, a common include file (/site/templates/blog.inc) was created to house shared functionality that is used by multiple templates. This file just contains standard PHP functions that the individual templates call upon. For example, the ability to render blog posts (whether full or summarized) is something utilized by several templates in the site. Unlike the basic profile, the blog profile delegates most of the markup/HTML generation to files in /site/templates/markup/. Most of these markup generation files are called upon by functions in that blog.inc file. This is very much like an MVC approach. While I think the approach may not have as much practical value on a smaller site, it does make the output very easy to edit. Most of the decision making happens in in the individual template files. While all the markup/HTML comes from the files in /site/templates/markup/. When you want to make markup changes to common output, the files in /site/templates/markup/ have this profile covered. In my own sites, I usually take a similar approach except without the /markup/ files. I usually bundle the markup generation right into the shared include file (like blog.inc). That makes it simpler for me to maintain, though the blog profile approach would be better when there is a team of people (rather than one developer).

I agree, cookies would be the way to set this up. You'd just set a cookie with the user's name and pre-populate the field with the name from the cookie (after sanitizing it with $sanitizer->pageName). You could do this with PHP or Javascript. But I'd probably use PHP just because the logic of figuring out when to store the value (after login) would be simpler from the PHP side.

This is really a great module and I'm enjoying using it. Thanks for your efforts here. I think it makes sense to have it in the 2.3 core. But for 2.2, would you mind adding this one to modules.processwire.com? http://modules.processwire.com/add/

The infinite scrolls drive me nuts. But I agree it would be fun to see how one has implemented this.

Guest access can't be turned off from the homepage because that's one checkbox that has potential to take down an entire site. It's built-in to reduce support burden. And it's in response to me having clients do this on two occasions and calling me in the middle of the night because their entire site went down. How they managed to do it, I don't know. But it convinced me that I shouldn't have a checkbox that can take down an entire site. I think that Teppo's solution is a good way to go. Another would be to put this in an autoload module (though I haven't tested): public function init() { $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); } public function hookPageViewable(HookEvent $event) { if($event->return === true) { $page = $event->object; if($page->template == 'admin') return; if(wire('user')->isGuest()) $event->return = false; } }

I agree with SiNNuT on this one, though the likes of Symfony aren't a social platform out of the box either. I think that unless you use a pre-packaged setup like those mentioned (buddypress, etc.) you will be custom coding many of the features. And ProcessWire is a good place to do it. But you'd probably want to start from the vantage of a smaller project with ProcessWire to evaluate and determine if it's the right framework for your needs.