Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/10/2012 in all areas

  1. Is there anywhere that we can donate to Ryan as thanks for his work? Not only has he built an incredible system here but he is both helpful and humble in his interactions with us. Even if there is no plans for a donation function I just wanted to say thanks.
    6 points
  2. We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules'). The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples: Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/. You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/. Those are simple examples, but this module can handle more complex situations too: Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/ Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects. You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL. TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.
    5 points
  3. Here's another option: $field = $fields->get('your_page_select_field'); $inputfield = $field->type->getInputfield($page); $options = $inputfield->getSelectablePages($page); The advantage is that it'll work with all selectable pages settings (i.e. template, selectors, code, parent). Whereas the previous examples assume the selection is built just around a parent (which is perfectly fine too if that suits your needs).
    3 points
  4. I would probably make current_team a single page reference, and past_teams a multi page reference. Meaning, two separate fields. Lets say that $team is a Page with the current team. A team could find it's current members like this: $riders = $pages->find("current_team=$team"); and past members like this: $riders = $pages->find("past_teams=$team"); I know I said before that I didn't think there was a place for repeaters here. But now I take that back. Here's an alternate approach that might be handy by using repeaters: You could setup a repeater called 'teams' and have it contain these fields: team (single page reference) year (integer or page reference) Then you could find all current members like this: $riders = $pages->find("teams.team=$team, teams.year=2012"); and past members like this: $riders = $pages->find("teams.team=$team, teams.year<2012"); The other option you mentioned: retired checkbox with first or last being current, also seems like a fine way to go. But that does make it harder to quickly differentiate between current and past teams, at least from the context of $pages->find(). So I think it may be better to use one of the options above. If you use the repeater approach mentioned above, you could add a checkbox to the repeater that indicates they are a participant. So if you wanted to find all partipants (the 6 rather than the 15) for $team in the year 2012: $participants = $pages->find('teams.team=$team, teams.year=2012, teams.participant=1"); Lets say you wanted to output a table like your example link: http://www.cqranking...r.asp?riderid=7 Here's roughly how you'd output that: $rider = $pages->get("name=lance-armstrong"); foreach($rider->teams->sort("-year") as $team) { echo "<p>"; echo "Year: {$team->year}<br />"; echo "Team: <a href='{$team->team->url}'>{$team->team->title}</a><br />"; echo "Participant: " . ($team->participant ? "Yes" : "No"); echo "</p>"; } Should give you a result like this:
    3 points
  5. I'm sure someone may already have posted this somewhere but I've only just come across it myself: http://www.opera.com/developer/tools/mobile/ Very handy as I only have an iPhone to test mobile sites on, plus this will test some tablet sizes too
    1 point
  6. I've been working for some time on an updated version to functionality of the cheatsheet and have commited it now. All code and functionality, no content changes. removed table layout and added the excellent Masonry/Istope js for block layout and filtering added setting for column count so you can change it to your best fit in the toolbar improved live search, especially in Firefox (which wasn't really working before) now sections not containing any filter results will be hidden (not get in the way anymore) These changes also will help adding more content to the sheet. Preparing to launch the rocket! Enjoy.
    1 point
  7. If I understand correctly, perhaps you could store your links as pages. Your 'link' template would have a 'title' and URL field called 'href'. You'd store these pages under /links/ or wherever it makes sense in your site. The 'link' template file code would just be a redirect: <?php $session->redirect($page->href); When you link to these resources in TinyMCE (or elsewhere) you'd link to the /links/some-site-link/ page(s). That would abstract away the actual link to be something that you could change in 1 place and expect that any links to it will get redirected to the right place.
    1 point
  8. Did you try http://www.responsinator.com/ . It has a more "device approach" then the other pixel based tools (http://mattkersley.com/responsive/). When you have the real devices maybe Adobe Shadow is your choice (http://labs.adobe.com/technologies/shadow/).
    1 point
  9. slkwrm, yes kinda, but won't work out of context and only if there's a page selected already.
    1 point
  10. @pete: it stores the target as the page ID rather than a URL so always going to redirect to whatever is the Latest ver of the page. (ie no extra redirects) @diogo: it doesn't look for redirects unless a 404 has already been triggered. So if the requested path matches a page in the system, a 404 never gets triggered and this module would not come into play. @WillyC: please try that out and report back what you find?,
    1 point
  11. Just as a little side note, i quite like the way the laravel framework presents their 'bundles' section. Of course, this could be modules as well. http://bundles.laravel.com/bundles/'>http://bundles.laravel.com/bundles/ http://bundles.laravel.com/
    1 point
  12. I use "ios simulator" what is in xcode ( you can switch between iPad iPhone etc. ), next to that, for breakpoints with media queries I sometimes use Remy Sharp's responsivepx.com. I think not the device, but the content should dictate when a breakpoint is needed.
    1 point
  13. Wiggins was on a roll today! On topic: Let's assume a rider has a permanent location (/riders/rider-name) and currently no team, because he retired last year. How would you structure this so you can output a list of former teams? And how would this be done so a team can show it's former members as well? Perhaps a checkbox 'retired' and assume the first (or last) team in an array would be his latest? I thought about this a while ago, but never came to a satisfying solution.
    1 point
  14. Thanks a bunch, diogo! I mean to say, {"text":"obrigado!"}
    1 point
  15. Great post! PW is a lot different than Drupal in this regard, but no less flexible. Between page references, structure, the API, and markup under your control, I think you can take PW further than you can Drupal. Another aspect of PW that I wanted to mention that is easy to miss: PW supports unlimited granular permissions. You can simply add new permissions in the admin (Admin > Access > Permissions). Then edit any roles you want to have those permissions and check the appropriate boxes. From that point, you can use those permissions in the API however you want. For instance, if you'd created a permission called "sugar-in-coffee" then you could check if the current user has that permission by using the API: if($user->hasPermission("sugar-in-coffee")) { // do something } Something else you may find handy is if you want to provide additional access without a user having to login. Lets say you are performing some check with the IP.Board API to determine if a user of a certain level is logged in there, and you want them to have upgraded permissions in PW at the same time. Create a role that has the permissions you want. Then you can assign that role to guest when you detect they should have additional access: if($user_is_logged_in_ipboard) { // or however you perform this check $user->addRole('member'); // where 'member' is the role you added // now user has more access } or if you want to login a specific user in PW, but don't need to authenticate (because they already authenticated in IP.Board): if($user_is_logged_in_ipboard) { $u = $users->get($ipboard_user_name); if($u->id) $users->setCurrentUser($u); // now a user is logged in for this request, without having to authenticate }
    1 point
  16. You also have to iterate the pages inside the page field foreach($page->banners as $banner) { foreach($banner->pagefield as $p) { echo $p->title; } }
    1 point
  17. Okay, so I've only just read this thread (I've been busy elsewhere ) so ryan is probably getting sick of the fact I've "liked" every other post in this thread in the last five minutes, but I do like it For mobile testing, you might like to try this ryan: Also, just my personal preference, but I've gone completely off Cufon in recent months and prefer to use the likes of FontSquirrel. I know it's down to personal preference from the designer's point of view, but it did occur to me that if you supported something like a standard site/templates/fonts folder then you could ship several fonts from fontsquirrel with the default theme (they're free) and even support dropping new fonts into that folder and have it tied in with a drop-down font selector in the admin area somehow. Just a thought, but I think something simple like that could be reasonably easy to implement for the benefit of non-web-savvy users. I love everything else about this and will be digging through the code at some point to see where I can use bits on some of my current sites, as well as using the whole thing for future sites. Keep up the awesome work!
    1 point
  18. That's a good point--I hadn't actually tried images on the RSS feed before. Here's another way you could do it: $contents = $rss->renderFeed(); $contents = str_replace("<img src=\"/site/assets/files/", "<img src=\"http://clintonskakun.com/site/assets/files/", $contents); header($rss->header); echo $contents; This problem should resolve itself in 2.3, as I'm planning to abstract URLs to IDs in textarea fields. The IDs will be resolved to the full URL at render time.
    1 point
  19. The considerations I mentioned about email verification with the comments are good reasons why PW doesn't do this by default. Things like that get taken advantage of when they are a default behavior that can be exploited across many installations. But in your case, it's less likely someone will be taking advantage of it given that yours be unique. If you really need to verify that the poster matches up to a specific email address, you would have to do email verification. So I think that if I were in your situation, perhaps I would go ahead and do it, as the benefits outweigh the drawbacks in your case. PW works nicely with comment services like Disqus and Intense Debate, so you may want to investigate the options there. But if you want to stick with using PW's built-in comments fieldtype, I think your best bet is to modify the one it comes with. I'm not sure exactly the strategy you'd want to use here, but what you mentioned about adding another status may be a good one. Though if compatible with your needs, I might just reuse the existing Comment::statusPending and have the email confirmation convert that to Comment::statusApproved. If combining with Akismet, you may want to manually handle any comments that get labeled as spam, or perhaps have the email confirmation move them up one level from Comment::statusSpam to Comment::statusPending (where they would be manually approved). Email me at ryan at this domain if you would like me to custom develop this for you. Or if you are comfortable on the PHP side, I'm here to help in the forum if you have any questions that come up along the way.
    1 point
  20. Here's an update on the blog profile. It now supports themes. The first theme I've made for it is based on Nikola's Futura admin theme: http://processwire.com/blogtest/?theme=futura I've also made a ProcessWire theme, but I think it still needs work (a little too girly right now): http://processwire.com/blogtest/?theme=processwire I'll probably put in one or two more themes for the distribution version. You can select the theme from the homepage. It's just a page reference field where it lets you select from pages using the "theme" template. The "theme" template is nothing more than a files field with all of the theme's assets in it. Typically this would be a CSS file(s), JS file(s), and images or font files (if used). I also had color pickers for defining the themes colors, but backtracked on that. I want themes to be self contained so that can create a new "theme" page, drag a ZIP file into the page, and be done with it. Once color pickers get involved, it becomes much less portable. Though I may still provide the option for overriding theme colors, but I have a feeling most people would prefer to just edit the included CSS file and then drag it back in. This version also is better optimized for mobile use. In addition to converting the top navigation to a <select> in mobile views, it now moves the search box and any other navigation to the bottom. That way people on mobile should still see the primary page headline and some of the copy without having to scroll.
    1 point
  21. More updates to the blog profile at http://processwire.com/blogtest/ Still not done with it, but lots of new tweaks. The biggest one is the addition of Tags, as well as an update to the InputfieldPageAutocomplete (committed today) that makes it work really well for tagging. Now when you are entering something in the autocomplete, if it doesn't match anything you can just hit enter and it adds it as a new page. This is assuming that you've configured the field to support that feature. Anyway, the point of this is that it's a very natural way of adding new pages with autocomplete.
    1 point
  22. Just thought I report back with an actual working method for this scenario. I needed to get the title of the next page (category) and create a thumbnail for that category using an image from the first project in that category. our-work - category1 - project1 (need first image from here) - project2 - project3 - category2 - project1 (need first image from here) - project2 - project3 if ($page->prev->id) { $prevThumb = $page->prev()->child()->images->first()->size(100,100); echo "<a href='{$page->prev->url}'><img src='{$prev->url}' /><br />{$page->prev->title}</a>"; } if ($page->next->id) { $nextThumb = $page->next()->child()->images->first()->size(100,100); echo "<a href='{$page->next->url}'><img src='{$next->url}' /><br />{$page->next->title}</a>"; }
    1 point
  23. 1 point
  24. Welcome to the forums abe.izar. Seems like they should make json_encode at least attempt to typecast an object to a string (which would convert to IDs here). Maybe I can update wireEncodeJSON (a front-end to json_encode) do that. However, if you really want to export pages and all their data to JSON, here's how you can do it: function pagesToJSON(PageArray $items) { $a = array(); foreach($items as $item) { $a[] = pageToArray($item); } return json_encode($a); } function pageToArray(Page $page) { $outputFormatting = $page->outputFormatting; $page->setOutputFormatting(false); $data = array( 'id' => $page->id, 'parent_id' => $page->parent_id, 'templates_id' => $page->templates_id, 'name' => $page->name, 'status' => $page->status, 'sort' => $page->sort, 'sortfield' => $page->sortfield, 'numChildren' => $page->numChildren, 'template' => $page->template->name, 'parent' => $page->parent->path, 'data' => array(), ); foreach($page->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen) continue; $value = $page->get($field->name); $data['data'][$field->name] = $field->type->sleepValue($page, $field, $value); } $page->setOutputFormatting($outputFormatting); return $data; }
    1 point
  25. Hey, it got me (who never got his mind around PHP in various attempts), into learning about strftime, strtotime, date and all that stuff this morning. So thanks PW for teaching me yet another lesson in PHP. Watch your backs, I might take the whole thing over some time.
    1 point
×
×
  • Create New...