Jump to content

Soma

Moderators
  • Posts

    6,808
  • Joined

  • Last visited

  • Days Won

    159

Everything posted by Soma

  1. You shouldn't exit (actually never) but use a flag ... if($page->skip) return; $page->skip = true; $page->save(); ...
  2. Save hook save hook save hook ... Add a flag to the page on first save and check for it to terminate.
  3. The pagetable stores the ids of the track. It's like a page field and you can use it to find the album the track is on.
  4. You don't need a reference as you already got one, it's the pagetable. You can get the page the entry belongs to via API find.
  5. The try catch is only a workaround for the Login Throttle... If the login isn't correct, you would do output a message somwhere in the if($u && $u->id){ $session->redirect("/somepage/"); } Like if($u && $u->id){ $session->redirect("/somepage/"); } else { $error = "Login failed"; }
  6. I've filed already a couple related issues with AIOM on github but no reaction so far since months. I think it's possible that minify html option causes it? Does it work when in dev mode?
  7. I'm using the page=image as with ImagesManager in some big project where there is or will be 100'000+ of images to manage. I have then built a fieltype I can select and insert them to a page from all those via filtering/search (ajax). We never insert image into a textarea via TinyMCE or CKeditor image dialog because it's cumbersome to use and manage, we rather use hanna code to have them inserted in a more controlled way (if at all), but often the better option is to use PageTable or repeaters to create block with text and image. This system is ultimatively flexible and PW provides all the foundation to use it how you want and need (unlike any other CMS media system). It's just a matter of creating some simple modules that may help you in that regard. PW is still in it's beginning and will certainly grow in that regard with modules that help with asset management. I just don't have the time to spend on that to share with the community. But time will tell.
  8. I'm not sure I can follow you. *confused* I think it's a matter of terms. To be more correct in PW termns there's Fieldtype and Inputfield. Fieldtype is more like the model while the Inputfield is the interface to the user, meaning resposible for rendering the value and inputs of a Fieldtype. Forms are build out of Inputfields. Now a "field" (if using the more general naming) added to a form (InputfieldWrapper) always has to be of type "Inputfield" . The error you got: You try to add a NULL to the form as the second argument! Now looks like your form get() call doesn't return a Inputfield but NULL so it's not found maybe. But you can easily test that. But you might know all this already. I'm not sure I understand, What "both"? InputfieldFrom (InputfieldWrapper) only allows Inputfields to be added, and not Fields (Fields as you get per a call like $template->fields. If you try to add those you get an error.
  9. In forms it's always inputfields there are no "fields". Works fine so it must be something you're overlooking.
  10. As far as I know you can only use showIf dependencies with fields, not page id's etc.
  11. The get() in InputfieldWrapper is assuming to get a field by name and is not using a selector like a find. /** * By default, calls to get() are finding a child Inputfield based on the name attribute * */ public function get($key) { if($inputfield = $this->getChildByName($key)) return $inputfield; if($this->fuel($key)) return $this->fuel($key); if($key == 'children') return $this->children; if(($value = parent::get($key)) !== null) return $value; return null; } You could also do $form->find("type=submit")->first->name;
  12. The endless link appending is because of the dot ./kontakt/ ... remove the dot and save a query.
  13. I love the spice girls!
  14. I was trying with my 160k testinstall Diogo's code doesn't work really as it has no correct start value and that would be something like the page's position in the result - 2 or something. So I tried with diogos approach and came up with adding a url segment to each article link in the list like /articleurl/1 to be able to get the position on the article page. //That would generate the list $session->list_selector = "template=news-entry, summary*=europa, sort=-date"; $limit = 10; $list = $pages->find( $session->list_selector . ", limit=$limit"); $start = $input->pageNum ? $limit * ($input->pageNum - 1) : 1; // $input->pageNum is the page from pagination foreach ($list as $key => $p) { $pos = $start + $key + 1; echo "<li><a href='$p->url{$pos}'>$p->title</a></li>"; // add position to the url } echo $list->renderPager(); And on the article page if($session->list_selector && $input->urlSegment1) { $pos = (int) $input->urlSegment1; if(!$pos) return; $limit = 3; $start = $pos == 1 ? 0 : $pos - 2; $selector = "{$session->list_selector}, start={$start}, limit={$limit}"; $array = $pages->find( $selector ); $prev = $page->prev($array); $next = $page->next($array); if($prev->id) echo "<a href='" . $prev->url . ($pos-1) . "'>Prev</a> "; if($next->id) echo "<a href='" . $next->url . ($pos+1) . "'>Next</a> "; } Works fine with a search with about (7) thousands of results in about 0.1 - 0.2 sec. This would be cacheable if you even construct the url using the category (if that's what you filter for only) and have those even cached results (hence own url). Another approach would be to cache a text file with the result (to not store big amount of data in session) and save and load that depending on the filter. A delimited list of ID's and use it to search to get the prev and next item in the list. Not sure this would complicate things but then the DB don't need to query each time (if that's at all a problem.)
  15. Or what about? $navigation = $page->siblings; or $navigation = $page->parent->children; Your both codes are the same if {$page->parent->name} returns "browse"
  16. IS that the real path or jus one segment. What if you try to get it with pages->get('/name/') to test instead of find.
  17. No PW isn't smart enough. But you. If that a on front end you just save the field and done. It's in your hand to page->save(field).
  18. Pager only works for single queries and not for arrays in memory or modified ones l. If you manipulate the arrangements after the find it doesn't work. You could set start limit and totals manually but then you'd have to load all first in a find without a limit. Works fine for smaller amounts.
  19. Your first post code works with if you remove the start=11.
  20. Have you enabled Page Numbers on template?
  21. Ah sorry, a form object is a InputfieldWrapper which is a special Inputfield, but it has Inputfields that are part of the InputfieldArray (defined at top of /wire/core/InputfieldWrapper). That's why replace(a,b) is not there for a form object. No you don't have to set it, just modify the field object and done, it's an instance and not a copy. Just as a hint. When doing all this form manipulation, just keep in mind that fields could be nested in case of fieldsets containing fields. There's also $form->get("fieldset_details")->children() etc... But you could also get a flat presentation of the inputfields with $inputfieldsArray = $form->getAll(); though not positive it's useful in your case. That should work fine.
  22. Output formatting is off because we are in the back-end. Pages loaded in any a module have it off, it's only on in front-end context. All normal, and no problem turning it on if needed.
  23. Yah as you speak $form->get('field') or find.. Basically it's a WireArray. Rings a bell?
  24. Cache field is for text only.
  25. I don't know what "dynamic behavior" you have there, but then you need some way to execute the same find query as on the listing page.
×
×
  • Create New...