Leaderboard

( ohne Worte - without words )

No, this isn't suspicious, it's me saying skoal.

(but wait! there is someone acting very suspicious...)

Lea Verou explains Regular Expressions. This is actually very easy to follow! Her RegExp playground is pretty cool too http://leaverou.github.io/regexplained/. And since we are at it, check out this Regexp editor by Cody Lindley http://jsfiddle.net/codylindley/u4E6P/

Very interesting tool from Mozilla, Just tested it on a site only by pasting a script,and works fine https://towtruck.mozillalabs.com/

Manual sorting is intended for reasonably sized lists, like navigation. For large groups of pages that have a chronological basis, you should always use some kind of date sorting. If you need to go outside that in certain instances, then add a "sticky" or "featured" checkbox, so that the client can override what gets shown first on the front-end when they want to. For example, if we wanted to retrieve a list of all news articles by date, but with "featured" ones showing up first, we could do this: $articles = $pages->find("template=article, sort=-featured, sort=-date");

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

Hi, I´m looking for a simple self-hosted helpdesk software (preferably PHP) that comes with a nice design out-of-the box (or at least one that can be easily styled). Been googling around for a while and found RT: Request Tracker (Perl). RT seems good, but I would like to get some opinions. ...or, maybe I should just get started building my own helpdesk with PW -Peter PS. Tested Ryan´s Pro Cache on two sites today and it's really lightning fast.............

If it is shared hosting, then it might be your neighbor who is getting all the visitors, but blocking the road for your house too...

I remember ryan saying that the questionmark indicates the error happened before Pw could handle the request. So I guess this means that the DB-error happens right at the beginning and Pw isn't able to detect the user or the page, because it can't access the database.

Sounds like you've got it right.

http://www.debuggex.com/

Dont you need to put the script outside after the div?

this another language.swatch work wit any num.languagees new localUrl func echo "<ul>"; foreach($languages as $language) { $class="$language"=="$user->language" ? "active" : ""; $url=$page->localUrl($language); echo "<li class=\"$class\"><a href=\"$url\">$language->title</a></li>"; } echo "</ul>"

Stop the drama you ...sensationalists!

importnant say mom to step in nother mans shoes get purspectives so i make new avoters for you so u can shares purspectivos togther can u work for briter futurre brothers.you are now

auther of imagine want to join pw mabe he work withe horst ? horst work withe pw not mammajoomla or daddadrupal mabe imagine nice but not as nice as havings coder horst withe pw

Finally had a chance to test this new functionality and have been really impressed. For those wanting to try, here are the steps that I went though using the default site profile. In the following examples I am adding two languages English and German where the pages will be viewable with the language code preceding the url like /en/ and /de/ 1.Install the latest development version - here is the zip download - https://github.com/ryancramerdesign/ProcessWire/archive/dev.zip 2. Install these 3 modules - Languages Support - Languages Support - Fields - Languages Support - Page Names 3. Add a new language via the Languages setup page - I think naming here is only relevant for your code and does not affect the URL of the page 4. Open up the home page and look at Settings tab - the name (url) field should now have a field for each language you have added. Add an indicator for each language like /en and /de English /en/ Deutsch /de/ This acts as a language gateway for changing the language. Now when ever you visit the site via /de it will set the users language to German and all the pages in the site will display the correct German language url. note: I have not worked out how to redirect the default language (which is English) to /en - it always goes to the site root / 4. Add a simple language navigation switcher. This will allow users to switch the current page into the other language. Edit : Refer to WillyC and Ryans language switcher further down - http://processwire.com/talk/topic/2979-multi-language-page-names-urls/page-3#entry33537 echo '<ul>'; $lang = $user->language; $langname = $lang->name == 'default' ? 'en' : $lang->name; $user->language = $languages->get('default'); $cssClass = $langname == 'en' ? 'class="active"' : ''; echo '<li '.$cssClass.'><a href="'.$page->url.'">EN</a></li>'; $user->language = $languages->get('de'); $cssClass = $langname == 'de' ? 'class="active"' : ''; echo '<li '.$cssClass.'><a href="'.$page->url.'">DE</a></li>'; $user->language = $lang; echo '</ul>'; I think that is pretty much it. All other PW development procedes as normal. I also just switched over from the LanguageLocalizedURL module on one site - it was actually pretty easy to do - just uninstalled the module and went through the steps above - thanks soma and mcmorry for the original module - it was very useful at the time, but will be moving over this mainly so I can start using the ProCache module. I have tested the new language fields with ProCache and it also works great! Super fast, one tree multilingual sites, with the same ease as developing a regular processwire site - this is so cool!

I regularely express myself.

I think you both have valid points from your perspective. I think it comes down to that we're having the current ImageSizer getting some enhancement and trying to keep improving it and not having a dependency on an other lib which would need to be maintained also. The matter image and all its facets is such a huge subject in web development it's hard to sometimes argue about it. It's great to have some movement here happen and we all appreciate the work you do horst. It's also nice to suggest a different approach but it somehow sparked unwanted reactions because theres some good free time spent here. It's like telling someone after building his dreamhouse why not buy a house thats already built.

$value = $pages->find( "title%=$q" ); $pa->import( $pages->find( "template=abc, …|…|…=$value" ) ); $pa->import( $pages->find( "template=abc, title%=$q" ) ); What should that do? You have to explaing a little more for a short minded like me. I have an example that shows how to construct your own pager using the PW PagerNav class: // include paginator class require_once($config->paths->MarkupPagerNav . "PagerNav.php"); $pa = new PageArray(); $res1 = $pages->find("template=xyz, title%=space"); $res2 = $pages->find("template=abc, title%=hal"); $pa->import($res1); $pa->import($res2); // config paginator $baseUrl = $page->url; $limit = 4; $start = ($input->pageNum - 1) * $limit; $total = $pa->getTotal(); $pagerNav = new PagerNav($total, $limit, $input->pageNum); $pager = $pagerNav->getPager(); // construct paginator markup foreach($pager as $link) { if($link->pageNum == $input->pageNum) $class .= "on"; if($link->type == "separator") $item = '…'; else $item = "<a class='$class' href='{$baseUrl}page{$link->pageNum}/'>$link->label</a>"; $pagerMarkup .= "<li>$item</li>"; } // output paginator markup echo "<ul class='pager'>" . $pagerMarkup . "</ul>"; echo "total: $total<br/>"; echo "start: $start<br/>"; echo "limit: $limit<br/>"; echo "<ul>"; foreach($pa->find("start=$start, limit=$limit") as $p){ echo "<li>$p->title</li>"; } echo "</ul>"; Also in my ever growing gist examples https://gist.github.com/somatonic/5420536

I found a documentation about the famous silk road by the swiss journalist Peter Gysling. Watch it: http://seidenstrasse.srf.ch/de/home.html You just have to scroll down, unfortunatly the site is in german but the pics and the technical realisation is just worth it.

PHP handles closing connections automatically, so this shouldn't be a problem. According to one source this behavior could be a bit inconsistent between various PHP versions though -- which version of PHP is your host running? Depends on how they're pinging your site. Are they using HTTP or just checking if your machine replies from certain IP or..? In the former case that could affect things a bit, although it still shouldn't make much of difference. If they're checking your site every minute or something like that you could still slow it down a bit. I'm not familiar with this particular service, but they'll probably have some way to decide the time between individual pings.. and if they don't, Pingdom is a very good and very configurable alternative

( this is the community from Ryans point of view )

Ryan, I'm really impressed, amazed at your level of productivity, responsiveness (and generosity)!

Scary that you can't reproduce this... Well, I just tested with latest version and now it seems to work as it should! The result of the previous test first example is now like this: Title: Space | Parent: Images Title: hubble-wallpaper-space | Parent: Space Title: hubble-wallpaper-space-647500_1600_1200 | Parent: Space Title: outer-space-stars | Parent: Space Title: space-space-584336 | Parent: Space Title: 1920x1080-wallpapers-of-nature-1249994468-1 space | Parent: Nature Title: nature_444_photos space | Parent: Nature Title: serena space | Parent: Nature Title: | Parent: Space Title: | Parent: Space Title: | Parent: Space Title: | Parent: Space ... So the pages with a "Nature" parent are showing now. So definately you fixed something that was causing this.

@totoff: that was just the name of the variable Ryan used in his example. See how he checks and sets it in the first code block? You can store any custom variables you might need in $session and then use them on any other page for that particular (user-specific) session: $session->referrer_id = $page->id; $session->interesting_fact = "Chuck norris can slam a revolving door.";

You can use the InputfieldMarkup to add custom markup. $field = $modules->get("InputfieldMarkup"); $field->markupText = "<p>your html string here</p>";

Ok, problem is solved thanks to Google and an older post by Michael Murphy. Turns out I needed to turn on "Allow page numbers" for the language-gateway.php template also.

You're mixing vanilla PHP with PW API. Selectors are PW specific. I don't know you guys know that you can also do this in PW (usually people miss this) if($page->is("template=home|basic-page")) echo "has template";

Don't be sorry you 've been a great help I finally been playing with the Authors template from the blog profile of Ryan I'm not sure what i did but it works i'm really discovering programming so I take it step by step again thanks for your tips

Hi, I made new site in processwire for one crazy Czech band http://www.jinovatka.cz/. Full content admin, responsive, gallery, mp3 player, .....

Just hitting my head to a wall with this: I have defined a field like this: $field = $modules->get("InputfieldRadios"); $field->label = "Gender"; $field->addOption('girl', 'Girl'); $field->addOption('boy', 'Boy'); $field->attr("name+id",'gender'); $form->append($field); and try to save the field after submit with this: $form->processInput($input->post); $uploadpage = new Page(); $uploadpage->gender = $form->gender->value; //OR $uploadpage->set($form->gender->name, $form->gender->value); But it doesn't save the field value. With Ryans FormTemplateProcessor module this template works, but trying to do the "dirty work" manually, I just can't get radiobuttons or checkboxes to save. What is it that I don't understand here? EDIT: OK, Soma helped me on IRC: Change $field->addOption('girl','Girl'); to this: $gender = $pages->get("/options/gender/")->children(); foreach ($gender as $p) { $field->addOption($p->id,$p->title); } This is because I am using pages as options. Then save the field like this: $uploadpage->set($form->gender->name, $form->gender->value); Thanks to Soma!

Hello, I'll take a look at this. For some reason, I have never really been able to get into SASS or LESS, and I tend to keep building CSS as CSS. But I always feel I am missing something, as everyone else seems to be using a pre-processor. Maybe something like Guard will motivate me? I suppose if I wait long enough, at least some of the pre-processor actions will become part of the CSS spec! Thanks, Matthew

Maybe, but as of Thumbnails is a visual Tool, I wish to have it like in my dirty Hack. plus one additional feature: If you have created a Thumb and quality isn't what you have expected, when you go back to recreate it, the CropRectangle should be placed automaticaly at its place, so you have only to select a different quality and / or sharpening pattern. (Just a dream, - but sometimes they become true)

ok, a little sum up. To understand what happens, here is the setup: Page called Clients, container for every client. every client got his unique number written to the title. The client template itself contains a set of round about 35 fields. I imported a set of data via CSV import Module. This set is provided by a client of mine who needs a new Intranet Solution. His client Database contains exactly 15987 entries. Every entry is one client and so every client is a page. As you can see in the screenshot, PW provides a automatic pagination. To handle this amount of data pagination is definitly not the best way. To edit and manage some clients you could use the built in search engine in the backend. Maybe I want to edit clients with the name Richard. I just pick my Clients Name field, type Richard in the Search box, et voila. What also could be interesting, is the performance of PW. Lets have a look: <? $pages->find('template=kunde'); ?> All clients in one PageArray gives me the following : Page generated in 33.5099 seconds. <? $pages->find('template=kunde,limit=50'); ?> Results in : Page generated in 0.0376 seconds. Rendering those sets of data doesnt affect our render time much. The following: <? foreach($pages->find('template=kunde,limit=50') as $client): ?> <p>Number: <?= $client->title ?></p> <? endforeach ?> Results in: Page generated in 0.0462 seconds. Conclusion: At a certain point you dont have to worry about how to order pages, instead you have to worry about how to catch your pageArrays as efficient as possible. Managing large amounts of data is somewhat to think about at the very beginning. I´m handling the clients in a tree like this: Home/Database/Clients/ Hope this was helpful

I'm afraid there's no selector you could use to filter based on nth record in a repeater. But there are other ways to get there. I'm assuming you've got a template "trip" with a repeater field "cities_repeater", correct? I'm asking because you're talking about a repeater but the structure (and get()->children()) looks like you've got pages inside each other. So, one option is to find all trips via Berlin, loop through the results and pick only those that have Berlin as a starting location. If the amount of trips starting from a city isn't going to grow too much (so that you don't need to paginate the results) and the amount of trips via a city doesn't get too high either, this would probably work out just fine. On the other hand, you can make the trips searchable with a selector based on their starting city with a little autoload module and a hook. Create a new field "starting_city", add it to the trip template and make it hidden. Then create a module hooking after Pages::save. In the hook check for the trip template and then populate starting_city with the first element of cities_repeater. And remember to save only the starting_city field to avoid an infinite loop . See Pete's example and Soma's comments in this thread for a code example. Now that you've got starting_city in a separate field it's a walk in the park to write the selector you're after: $trips = $pages->find("parent=/trips/, starting_city=berlin"); Do remember that in order to get that hidden field populated for all the trips, the hooking module must be installed before any trips are actually created. If you've already got the data in place, then you need to get the module working and either save each trip (no changes needed, just edit+save and the hook will kick in) or create a little script that populates the field for the first time.

Peter, depends what you have in mind. You can create custom admin pages and build your form using PW forms and API, so building on the foundation. The thread teppo linked to shows how to use inputs and form, whether for frontend or backend. Using PW components gives to plenty of possibilities to validate and manipulate and hook into various parts of the form and it inputfields. There around 400 hookable functions in PW http://processwire.com/api/hooks/. With this at your fingertips you can do almost anything pretty quickly, whether in backend or in front-end. It depends (as always) a lot what exactly you want to build and what the need are in detail and then look at what would fit best. Also remember all the PW backend stuff is built out of modules exactly the way you would build custom admin functionality and you always can look at how it's done or copy a module to site folder and start modifiying it. You could create your own admin pages and build mini apps that help editing, creating content and it's pretty straight forward. It would be in the same way for when building it in front-end. PW doesn't have a solution to all ready, but a strong foundation to build anything you want. I'm not sure what else you need to know or what you're exactly have in mind. I think you're still maybe need to play with that stuff to better understand all of that stuff and how to go about it in PW. So you should slowly start building custom admin pages I think and ask away.

Hi Peter, Just wanted to point out that there are couple of interesting discussions related to custom forms around; this one for an example. Essentially you'll have to create a form, by using PW elements or your own, and mostly put the logic together yourself. Depends of course a lot on what you're trying to achieve; simply sanitizing and saving user submitted content to pages (or users or..) is very simple to do via API, as you most likely already knew Lately we've been using Ryan's great Form Builder for almost all of our front-end custom forms stuff. It's super versatile and in the long run saves so much time that it's well worth the cost ($39.00 USD for one site etc.)

I really think the best way is to use pages. If you organize things well, those pages will never get in the way of the main structure because they will be collapsed under their parent. This is how people organize data in computers for years. The fact that you use pages will allow you to use the api, and this will make it so much easier to create a frontend or backend system to consult that data.

I've been making regular updates on the dev branch to the LanguageSupportPageNames module, so if you guys are using this, you may want to keep track of the updates. The good news is that this module is now running a production site: http://tripsite.com/cruises/ (only the /cruises/ site, as the rest of the site is running on a different copy of PW). This morning I pushed an update that makes it easier to tell if a given $page is viewable in another language. Now you can do this: if($page->viewable($language)) { ... } // Language object if($page->viewable('es')) { ... } // Language name That is basically telling you if the page has its "active" checkbox checked. Since these pages would already be excluded from search results, you don't typically need to use it except when on a given page and trying to determine what other languages that page is available in (like if you want to link to them, as the select box at the top of tripsite does).

I just pushed an update to 0.0.2 to github. Some refactoring and some changes - changed image tag syntax to use selector string syntax. This is easier to handle and I can use the PW selector class to read key=value easily. Now supports: {image=/path/, width=200, height=200, class=someclass, id=myimage, rel=album} - improved image upload to use the image field settings for max size settings, also improved error handling there- added some translations string - changed data table some and added a input for the tag where when you click it will select the tag text automatic for easy copying. - added modified date (sortable), also fixed some stuff with sortable of other cols - added size col - improved data table live search to search for also image description or image description field and title Planned - improve upload even more if/where possible - add easy image delete function - (Done) add textarea fields setting, to only insert "ImageManager" button to those specified Any testing or help appreciated. Thanks