Leaderboard

I think you can just use the normal API so: if your page field links to multiple pages: foreach ($page->page_links as $link) { echo "<h2>$link->title</h2>"; echo "<h4>$link->other_field</h4>"; } if not, it ought to just be: $page->page_link->my_field

I personally think the Cheatsheet should be made into a nice tea-towel that I can frame on the wall. Just a bit on docs - the ideal (for me, at any rate) would be to have the cheat sheet, complete with its short hand explanations (which are good!) and then a link to a longer explanation and real-world example or two. If anyone ever writes one anything for any of the items on the Cheatsheet, stick it on the wiki, or send it to me and I will stick it on. That must have been fun! (And potentially a bit of a shock for the unwitting....) Joss

Hi, just wanted to let you know, that I started another gist for this here: https://gist.github.com/4258927 I added the word count thingy and some smaller tweaks, but I'm definitely going to add the rest (particularly proper documentation), when I find time for it. Thanks, Soma, for kickstarting me on this! Ah, and another question for everyone: Would it be more elegant to integrate the functionality for plain text inputfields in this module or would you prefer to have it as a seperate one?

Updatery I just pushed v 1.0.3. to the master to https://github.com/s...nic/ColorPicker added support for default value added reset link to set back to default color some cleanup and added readme finally updated first post

ProcessWire DataTable 1.0.0 (https://github.com/somatonic/DataTable) This module enables you to find and edit (fancybox modal iframe) pages at a small and very large scale. So far it has: ajax suuport masked pagination state saving (datatable using cookie, template filter using session) template filter (only showing templates user has edit access) search text filter (using title|body field) multilanguage support (PW's language translator) Superuser will see all pages and system templates. Users only those with view|edit access and pages in trash. This Module is still very simple and only in "lazy" developement and testing and this is the first official release mainly to get it out for others to see and use. It also could provide as an example/kickstart for someone. Everyone is encouraged to help and contribute to further improve or add features. The module is hosted on my github account: https://github.com/somatonic/DataTable The plugin used in this module is the excellent jQuery Plugin DataTable 1.8.2 - http://datatables.net/ I've chosen it, because I used in in some other web projects and was really happy about it's power and ease to setup. It supports jQuery UI styling, which makes the deal perfect for a ProcessWire module. Thanks and have fun trying it out. ------ (original post, kept for nostalgic moments) Ok, I started trying to implement the great jQuery dataTables plugin into ProcessWire. So far it works very well and is very powerful and fun. Best of it it support jquery themeroller. Not sure how far this all can go with configuration and how to define which pages should be displayed, what collumns etc... Many many things to consider. But if it could provide as an example on how to implement it, it would be great tool for site builders. Here you can see a short video of how it looks and works.

I have not dug into the admin theme possibilities much, however, I have a feeling that what I am thinking about is not possible without treading on the core rather a lot. I like the fact that the admin is very straight forward, but I do get lost from time to time. By that I mean That if I work on something like a field or a page and want to play with a different one, I have to get back to where I started rather than jump from one to another. My thought would be to have a top bar with the main links, just as now. But when you go to pages, the page tree is in a left sidebar and any pages you open to edit are on the right main pane. This means that visually you always know where you are. The problem is how to incorporate the rather nice moving of pages and things like bringing up "edit view new move" and so on. One possibility is to use Jquery to create a right click menu on a page item - that would probably get round the problem and would allow for more options that might appear in the future "archive, email to my granny, feed to the dog, etc" Where sidebar trees run into dificulties is when you have lots of sub levels and it gets wider, or someone has a really interesting long title for a page! The way things like PhpMyAdmin do it is simply to add a horizonal scroll bar - which I hate, to be honest. May it is better to have it as a sort of mixture between a tree and navigating through folders. So you would have your top level pages to start with. If one has a child, you can click on its "open children" icon and the menu is reloaded with that next level. Top levels are still visible, though slightly greyed out. There is no indentation. If you go to a sub-sub level, the same thing happens. You see the list in the sub-sub level, but you still see the other Top level items (not the sub level, perhaps) This does not give you complete vision of everything, but it is probably manageable, especially if you have a lot of sub levels and a lot of pages. Titles possibly should be truncated. I am a great believer in a two-title system anyway. One for list sorting purposes and another one (or more) for displaying on the site. The same navigation system would obviously be used for Fields, templates, modules, template files and anything else that might appear in the future. Anyway, that is just some idle thoughts before bed. Joss

I think there are a few things to bear in mind here: You will need to know a fair amount of PHP to proceed. No CMS will allow you to simply port functions from another CMS by replacing X with Y - the functions will usually interact differently with the core code. A clumsy example is that it's essentially like taking wheels from a quad bike and trying to attach it to a monster truck - yes they're both wheels but they are incompatible and there will be a lot of effort involved in making them work together. It may well be easier to add your required functionality to the shopping cart module diogo mentioned: http://modules.processwire.com/modules/shopping-cart/ - again though you will need to look at that source code and be able to code PHP to continue If you're happy coding PHP, there are several topics to help you on your way to understanding ProcessWire modules Firstly, read up on the documentation on the site - you will need an understanding of how the system works first: http://processwire.com/api/ Next there is some useful information on creating modules here: http://wiki.processwire.com/index.php/Module_Creation and here: Finally, the cheatsheet is handy to have to hand: http://processwire.com/api/cheatsheet/ Let us know how you get on.

Specially designed just for you

Which begs the question, which sort of website? From the planets tutorial you can see how to create a basic sort of website, but what if you want to add a gallery, or create a contact form, what about meta data? There are a lot of variations and it would be difficult to guess someone's priorities. So, how about this? Stage One So, you start with a fairly agnostic site with a header and footer - incredibly simple framework with a masthead banner, menubar and common footer with text and a logo in it. Dump the side bar for the moment - it is a distraction. So you would want to cover getting rid of stuff you dont need. Also, do some housework like change the name of the admin page, add a couple of very useful modules (crop image, module manager,repeater, etc) iand update the JQuery for the front end of the site. Next create a site settings template (without file) and page combination for site name, site meta keywords and description and a top banner image and demonstrate how to pull that data into your header and footer. And then you edit the home page information just to make sure it works. That is the intro. Stage Two - well, lots of stage twos After that you can fork out with child articles. Each one can cover one scenario: news page, contact form, team page, Flexslider show, and so on. Each one must fit into the site created with stage one and must not conflict with the other child articles. That way, users can find their own route through this based on their own priorities rather than having to wade to the bit they are interested in. As an offshoot, it would also make clear some good ideas about how to manage a site as it becomes more complicated by getting the planning at the beginning right. This is a good way of getting some new website people in before they go and weld themselves to Droolapress (see what I did there?) while saying to more experienced users, "we know what your most common tasks are, so here they are, ready to go." Joss

Choose the most important for you and ask one at a time, like this is not possible to help...

This is a joke not?

echo "found: ".$pages->find("template=match, team_1|team_2=$user->teams");

Check the GD library, You can do it quickly like this: <?php if (extension_loaded('gd') && function_exists('gd_info')) { echo "hm no, GD is not the problem..."; }else{ echo "ah! I think we found it "; }

I have printed the cheatsheet on large paper & sticked to the wall . tnx Soma (I wish I could create a large PDF from it & let it print very large)

U scared me Soma D:< Ehm, no not really i think... It seems okay... if i just put 1 team in there it works... But multiple doesnt...

Hi apeisa, thanks for the quick answer! The hint with $page->viewable() is very much appreciated, I didn't think of using it for this because I thought, it was only concerned with access rights management and not with the page status itself. Very good to know for a lot of use cases. Still, this doesn't really cover my use case, because I want to explicitly echo both statusses for unpublished and hidden. I'm just going with something like this now: echo $page->is(Page::statusHidden) ? 'hidden' : 'not hidden'; echo $page->is(Page::statusUnpublished) ? 'not published' : 'published'; I'm totally fine with it. I just had it with $page->isHidden() before which looked strange and made me feel like I missed something at some point. So, not really a need to change, just a little incoherence here. On the other hand, to make it coherent it would need to either provice a convenience method for all statuses (which seems a little over the top) or to omit them all (which breaks backwards compability). It seems the best way would be to leave everything as it is.

We've encountered a problem with Blowfish-hashed passwords when using PW 2.3-to-be (dev-branch). Setting or changing a password breaks it so that the user is unable to login - not even right after otherwise successful installation. I've done a fair amount of reading, digging around and testing various things trying to understand this - and yet I'm not quite sure whether it's a PW bug that needs to be fixed (and how) or a PHP bug in certain versions that some of just have to get around in a way or another. My apologies for the way too long post - just wanted to give all the information to whoever is able to grab this thing and check the facts for real. Let's get to the details. What I found the problem to be is that PHP crypt() requires for the Blowfish salt to be at least 22 digits from the given set, but only when PHP version is around 5.3.2. As 5.3.0 introduced internal Blowfish implementation in the first place and 5.3.7 fixed a security bug in it, I'm assuming this could be the version range affected. PW 2.3 creates salt for Blowfish by using only 21 digits + a '$', which seems to be just fine in most cases. However, according to http://php.net/manual/en/function.crypt.php, there should be one more digit from the given alphabet: Then again, the answer at http://stackoverflow.com/questions/4683350/blowfish-salt-length-for-the-crypt-function does state that salt should be 21 chars + the trailing $ as currently implemented in PW 2.3. Dollar sign seems to be commonly used separator/terminator for salt strings in *NIX at least, but that PHP.net article doesn't say it should be used. I'm nowhere close to an expert on this, but according to my tests the $-terminator is not required. Here's some more information on the matter to digest (feel free to dive in, but don't blame me if your brain melts during the process): http://stackoverflow.com/questions/2225720/why-does-crypt-blowfish-generate-the-same-hash-with-two-different-salts Here's a little script I used to check for PHP version differences: #!/usr/bin/php <?php $salt20 = '12345678901234567890'; $pw = 'test'; // see if Blowfish hashing is possible var_dump(CRYPT_BLOWFISH); echo "Hash with salt20: " . crypt($pw, '$2a$11$' . $salt20) . "\n"; echo "Hash with salt21: " . crypt($pw, '$2a$11$x' . $salt20) . "\n"; echo "Hash with salt22: " . crypt($pw, '$2a$11$xy' . $salt20) . "\n"; echo "Hash with salt23: " . crypt($pw, '$2a$11$xyz' . $salt20) . "\n"; And here are the results for the few PHP versions I was able to test this on: PHP 5.2 had no Blowfish support. PHP 5.3.14+ (at least) pads under 22 digit salt with extra $'s or takes the first 22 digits from a longer salt string. PHP 5.3.2 does the same for longer strings but fails to return any valid hash for salt with less than 22 digits (this being the very problem we encountered). Here are the changes I made to get things working for us. Generate 22 digits instead of 21 and separate 7 ($2a$11$) + 22 (random salt) = 29 digits of salt instead of 28 (29th would be the trailing $) from the resulting hash. $ git diff wire/core/Password.php diff --git a/wire/core/Password.php b/wire/core/Password.php index 5ae8668..96a019d 100644 --- a/wire/core/Password.php +++ b/wire/core/Password.php @@ -103,7 +103,7 @@ class Password extends Wire { // if it's a blowfish hash, separate the salt from the hash if($this->isBlowfish($hash)) { - $this->data['salt'] = substr($hash, 0, 28); + $this->data['salt'] = substr($hash, 0, 29); $this->data['hash'] = substr($hash, 29); } else { $this->data['hash'] = $hash; @@ -134,7 +134,7 @@ class Password extends Wire { $len = strlen($chars)-1; // generate a 21 character random blowfish salt - for($n = 0; $n < 21; $n++) $salt .= $chars[mt_rand(0, $len)]; + for($n = 0; $n < 22; $n++) $salt .= $chars[mt_rand(0, $len)]; $salt .= '$'; // plus trailing $ return $salt; The trailing $ doesn't seem to be required but does no harm either. The nasty thing here is that anyone having let the current version write Blowfish hashes to the database would be left with broken passwords if the salt generation was changed like this now. We decided to fall back to old hashes until this has been solved properly (- make supportsBlowfish() return always false to have it this way). Better way for us would be updating PHP to a more recent version, but we're still using Ubuntu 10.04 LTS which only has PHP 5.3.2 by default. So we'd have to either upgrade the OS or tweak a little to get the current one running with PHP 5.3.10 for example. Another associated thing with Blowfish crypted and salted passwords if that if one sets up a site using current PW 2.3 with PHP 5.3.0-5.3.6 installed, all the passwords will be corrupted when updating PHP to version 5.3.7 or above. See http://php.net/security/crypt_blowfish.php for details. The passwords can be fixed by replacing $2a$ with $2x$ for the old hashes, but there's no bullet-proof way for PW to correct this on its own. And there shouldn't be as those old hashes are a security risk after all. Newly created passwords would work perfectly though, so instructing users to request a new password might be one way to get over this scenario. Phew. Over and out.

@adamkiss, I got some time to do this, but that would be tonight.

You can set the cache time to zero: $cache->get('your_cache_id', 0);

Adam, in modules you need to use $this->_()

I have just dipped my toe into the large space that is the ProcessWire wiki. At the moment, that just means that I have just logged on and am just creating a couple of templates and some other bits and pieces - nothing complicated, I don't have enough time! Once I have done that, I will start scribbling. For the moment, all I have done is a half complete help page about starting a new article (click on help in the left navigation), and created two categories - Drafts and Pending. Hopefully this will help with anything anyone writes which they want to flag up as not finished or need checking. More info on the help page. Talking of categories - if someone has any good ideas about what categories should be created and how they should be organised - that would be really useful! Joss. (PS: If anyone needs a logon for the Wiki, please ask Ryan, not me!)

Hello Macrura73, Well, what do you know... Another Joomla move. I wonder exactly how many of us are here on the forum? Is there a way to do this in ProcessWire: $formerjoomlausers = $members->find("joomla=was"); foreach($formerjoomlausers as $formerjoomlauser) { echo "<li>$formerjoomlauser->name</li>"; } Thanks, Matthew

Feel free to take it and improve it. Make it your own whatever and be sure to submit it to modulers page. You're welcome. Glad if it helps people.

Diogo - That is a very good point! Thanks Apeisa - Yes, I have been using for blocks in boostrap templates, but I agree, it is better to be more focused and pull specific information in other uses. I suspect that the "Pages" section of the Wiki and any subsequent manual is liable to become the most complicated and thus, the hardest to understand. It really needs to be broken down into specifics - use this for this situation - so that users can make a really good judgement on which way to go. Perhaps it could do with a sort of Best Practices article that lists the methods without the fine details so you can browse through and say "that is the sort of thing I want to achieve" and follow the link through to the detail. You guys up to helping on that? Joss

Nice idea, I was also thinking about some time ago. One way is to not extend the InputfieldTextarea, and make a new Inputfield type, but Hook into the necessary methods to extend the config and rendering. Since this made me wonder how it would go, I gave it a try. It's a nice example showing how to archive it using hooks only. It will give you a extra Input setting "Max length" in the field setup. And a counter for all InputfieldTextarea (not tinymce fields) and add a attribute "data-maxlength" to the one that have a max length value. I had to use "maxchars" as the setting field name as there's already this attribute, but not used in the context of page edit. The script js is also added via a hook, and is a basic example of the script that counts backward while typing. Since I was already that far it was easy to add, but you might want to modify it and add features if you like. This took me roughly 30min, and little more to add the js. I think a year ago I wouldn't knew how and would have taken ages to figure out. But it grows on you after so many modules and insight. This module shows you some good practices and maybe helps understanding modules. If you have questions please bring them in. Module code: https://gist.github.com/4252958 JScript code: https://gist.github.com/4252962 Put them in a folder /site/modules/TextAreaCounter/.. Install, enjoy. Edit: just found an issue... will take a look again

Why is koding.com going to Soma's module manager?

That sounds pretty much right. After moving PW from public_html/folder to public_html things should (mostly) work instantly, but one thing you will need to take care of are in-bound links; if you've created links to local content, they're probably relative and pointing to /folder/whatever-link-target/. You could either change these links directly from database, install Page Link Abstractor to handle this for you or use this little snippet by Soma. Another option, of course, is to export a page profile and re-install PW at public_html with that. This won't take care of the link problem, but in that case it would be quite easy to replace all "old" links in MySQL dump before running install process.

Can you try with 33% 34% 33%? That's what I use and haven't had an issue

I found Janko's FormToWizard code to be one of the simplest ways to implement a multi-page/multi-slide form. Now with the Processwire this just got easier. I tweaked his script a wee bit to work with the API forms described in this thread. PWformToWizard.js bunching your fields into fieldsets just as Ryan described above, each fieldset will become a page/slide. Instead using the <legend> tag that Janko uses, the script now generates a legend based on the label, specifically anything that comes before a colon ':' first add the script: <script type="text/javascript" src="PWformToWizard.js"></script> then use this javascript to initiallize formToWizard: $("#SignupForm").formToWizard(); the default styles are: <style type="text/css"> body { font-family:Lucida Sans, Arial, Helvetica, Sans-Serif; font-size:13px; margin:20px;} #main { width:960px; margin: 0px auto; border:solid 1px #b2b3b5; -moz-border-radius:10px; padding:20px; background-color:#f6f6f6;} #header { text-align:center; border-bottom:solid 1px #b2b3b5; margin: 0 0 20px 0; } fieldset { border:none; width:320px;} legend { font-size:18px; margin:0px; padding:10px 0px; color:#b0232a; font-weight:bold;} label { display:block; margin:15px 0 5px;} input[type=text], input[type=password] { width:300px; padding:5px; border:solid 1px #000;} .prev, .next { background-color:#b0232a; padding:5px 10px; color:#fff; text-decoration:none;} .prev:hover, .next:hover { background-color:#000; text-decoration:none;} .prev { float:left;} .next { float:right;} #steps { list-style:none; width:100%; overflow:hidden; margin:0px; padding:0px;} #steps li {font-size:24px; float:left; padding:10px; color:#b0b1b3;} #steps li span {font-size:11px; display:block;} #steps li.current { color:#000;} #makeWizard { background-color:#b0232a; color:#fff; padding:5px 10px; text-decoration:none; font-size:18px;} #makeWizard:hover { background-color:#000;} </style> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script> <script type="text/javascript" src="formToWizard.js"></script> <script type="text/javascript"> $(document).ready(function(){ $("#SignupForm").formToWizard({ submitButton: 'SaveAccount' }) }); </script> see janko's page for more info~ Now, just to add some responsive jquery validation to each 'next' button...

Is it just me or are processwire designer/developers a classy group of people? All these sites I keep seeing are well designed, expertly executed, all around quality work!

"Is it safe?"

Marc, let me know what you find. I just need some way to reproduce it, but once I can do that I can fix it quickly. If I can't reproduce it here, and you don't mind giving me access to troubleshoot your install, I'll be glad to do that.

I know, but this is how choices work in PW. You'll get used to it