Leaderboard

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

Well, if you want to do literally that $page->parent->children but this is better $page->siblings or, to exclude the current page $page->siblings("id!=$page") or $page->siblings->remove($page)

No need for a dependency management here, just load the tags/categories in another fashion: https://processwire.com/talk/topic/9730-get-pages-used-by-a-pagefield/

My name suggestion would be: RockettForms

A great idea - I've been thinking about something similar for a while but just don't have the time myself so will be keeping an eye on this with interest

Sounds interesting. Here's one way you can do it: $table = $fields->get('your_page_field')->getTable(); $query = $database->query("SELECT data FROM $table GROUP BY data"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $items = $pages->getById($ids); // $items is a PageArray echo $items->implode("\n", "<a href='{url}'>{title}</a>"); If we were to add this to the API, I think I'd want to make it accessible from a regular find() selector, rather than as a separate findSelectedPages method. That way it could be used with things like InputfieldSelector. Perhaps something like this: $pages->find("your_page_field=:selected"); ...where ":selected" is a keyword is would recognize to execute this behavior.

Edit: The title of this post has been renamed to use the word "processor" instead of "builder" - this is not a form-building module. I'm currently putting together a simple developer-centric form processor for one of my projects, and have decided that I'd like to release it as a module as soon as it's stable enough. The idea is to separate it from the backend, and use per-form configuration files and templates instead. I could well implement a backend solution for this, but my preference is for it to be developer-centric. For me, this makes it easier to use and, of course, develop. Here's how it currently works: developer specifies forms and their particulars in a JSON file stored in the module's directory. The file includes dictations such as the name of the form, the fields it uses (along with their sanitization/validation rules), template information, and a set of emails to send when the form is being processed. An example of such configuration is: { "contact": { "name": "Contact Form", "fields": { "name": { "sanitize": "text", "rules": { "required": "Please enter your name." } }, "email": { "sanitize": "email", "rules": { "required": "We need to know your email address so we can get back to you.", "email": "That doesn't look like a valid email address." } }, "company": { "sanitize": "text", "rules": { "min(4)": "That's a tad short for a company name." } }, "contact": { "sanitize": "text", "rules": { "int": "Please enter only the digits of your phone number (no spaces or other punctuation)." } }, "message": { "sanitize": "entities1|textarea", "textField": true, "rules": { "required": "Please enter your enquiry/message.", "min(250)": "Please enter at least {$0} (but no more than 2000) characters.", "max(2000)": "You have reached the {$0} character limit. Please shorten your message." } } }, "info": { "fromName": "The ABC Accounting Team", "tel": "(011) 100 1234", "altTel": "(011) 100 5678" }, "emails": { "autoReply": { "template": "auto-reply", "to": "{input.name} <{input.email}>", "from": "ABC Accounting <noreply@abc.accounting>", "subject": "Enquiry/Message Submitted - Thanks!" } } } } As seen in the 'emails' key, templates can be defined for each email. These templates can be plain/HTML/both, and accept information regarding form input, the 'info' key, and a custom stylesheet, which is created as a file, but imported directly into the HTML version of the template. The module will also come with a jQuery module to assist in processing the form. Frontend is up to the developer/designer. Currently, the directory structure of the module is: root - forms.config.json / templates / form-name - template-name.html - template-name.css - template-name.txt I'm now thinking that it would be better to change the structure to this: root / form-name / templates - template-name.html - template-name.css - template-name.txt - config.json That is: each form will have its own folder containing configuration and templates. So I'm starting this thread to ask the following: Firstly, what do you think of this idea, and do you think you would make use of this module? Of the two structures above, which one would you prefer? Would you want the ability to make use of attachments in your emails (such as a logo)? (If I'm not mistaken, we'd then need to require WireMailSmtp or WireMailSwiftMailer...) As a side note, it's worth mentioning that this module is really intended to be used on small- to medium-sized sites that require multiple forms where developers are not in a position to obtain Ryan's excellent FormBuilder. Any input here is most welcome. (And yes, as gathered by my signature, the module is called SimpleForms. If you have a name suggestion, please feel free...)

Hi Forum, I recently had a chat with a friend who was introduced to PW by me. He said: "brilliant cms, poor documentation." His comment makes me think about the cheatsheet: While we see new API methods introduced at a very fast pace, the cheatsheet doesn't seem to keep up. That's sad, because it's such a good resource. So, how can I (as a user with very limited PHP skills) help to update the cheatsheet? Is somebody skilled willing to team up with me - as kind of a supervisor - for the update tasks? Or are there any plans on behalf of the team to update the cheatsheet? Thanks!

Like others here, I build sites that require reuse of images. In my case, the images must always be accompanied by correct credits and descriptions, and must be replaced sitewide when our contract with the photographer ends. So centralized image storage is a must, and one page per image works fine. The challenge is selecting image pages from other pages in an easy, visual way. Soma's images module is a great move in that direction, but for my needs, users should work only with thumbs, never with HTML. The default pages field seems like it's allllmost there. I'd just like one of the field label choices to be the image field, and to choose a page by thumbnail. Ideally, the thumb will be shown on the page after selection, as it is with the images field. Even more ideally, the page picker will include search. Even even more ideally, I'd have the time and php chops to build this module myself.

What about a ProcessWire Day , when we could all celebrate ProcessWire? I know we do it a lot of days already...

take a look at image list label to get thumbnails in the pagetree....so this thumbs are shown also in the pagefield select... some hints to change the image select to a central parent where all subpages are images (usefull if you choose images in WYSIWYG) https://processwire.com/talk/topic/7439-processpageeditimageselect-hook-and-change-default-page/ a little project with some details (at the end of the post you see a pagefield select and the custom adminpage with pagetree with only the images with thumbs) https://processwire.com/talk/topic/7836-cant-wait-first-project-with-pw-nearly-finished/ On some little projects i'll stick to central imagemanagment - but on most sites i've adapted the PW way to connect images to pages... But it's all your choice just some hints to may a easy solution. Best regards mr-fan

Yeah, that's what I thought about. It's just that I don't like to pollute the admin section of the page tree with things, that aren't admin related, but content.

Thanks diogo. I do appreciate the help. Still feeling my way around Processwire (came from Wordpress) and I still am trying to tackle things with that mindset.

What.... NO COFFEE !!!

I knew I'd seen that post, but couldn't find it.

Thanks Martijn! After changing the sanitizeValue method the trailing slash is no longer needed. Field dependencies still don't work, but I did not expect it either Thanks for looking into it, but in my current project I can totally live without it. It's just a "nice to have", and I wanted to give you some feedback.

In case (perhaps it could have helped you): Redirects: http://modules.processwire.com/modules/process-redirects/; Jumplinks: http://modules.processwire.com/modules/process-jumplinks/.

I found a solution with an apache rewrite rule that removes index.php from url RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC] RewriteRule (.*?)index\.php/*(.*) /$1$2 [R=301,NE,L] source : https://ellislab.com/expressionengine/user-guide/urls/remove_index.php.html

I like this idea! In my former CMS there was a developer that works on all his addons with a basic form-addon that works with exact this methode (json for setup, twig .htt template files for the HTML Output) he called that forms "presets". So answering your questions: 1.)idea is great for every frontend development that usecases are a)simple forms easy to create without ravish backend inputs for forms or rely on other modules b)complexer setups for frontend forms of different types that are easy and very fast to develop with the same schema 2.) keep every form data (json/html/..) separate so structure 2 has my vote - It keeps the filetree clean i think 3.) Would always go for that feature since many forms are have attachments today like applications, userimage upload, image uploads for special propose (on a older site i've just a little form for a village where people could send a foto from a damage or request on the inframstructure/lamps and so on) 4.) wiresmtp or swift should be a better choice than normal PHP mailer... One question on my side. How do you wanna handle the HTML templates and the processing of the inputfields? Could i setup a schema or preset for the HTML output of every inputfield (for example to get bootstrap or UI Kit output) or you catch the replacements of processing with some sort of template engine or simple PHP tags...? Best regards mr-fan

You need an extra ) before the continue. If you count 3 ('s there should also be 3 )'s

you have some options... <?php // version using PageArray(); $kids = $pages->find("template=poi, has_parent=$page"); $interests = new PageArray(); foreach ($kids as $k) $interests->import($k->interests); echo '<ul>'; foreach ($interests as $i) { echo "<li><a href='interest/$i->name'>$i->title</a></li>"; } echo '</ul>'; // or find all interests, cycle through but ignore those that don't apply to this page $interests = $pages->find("template=interest"); echo '<ul>'; foreach ($interests as $i) { if(!count($pages->find("template=poi, has_parent=$page, interests=$i"))) continue; echo "<li><a href='interest/$i->name'>$i->title</a></li>"; } echo '</ul>'; ?> wow, 3 replies!

You could filter them out in a temporary array...e.g. //example code $interests = $pages->find('template=poi, interests!=""'); //method 1 foreach ($interests as $int) { foreach ($int->interests as $p) {//interests is a multi page field; PW returns them as objects $array1[$p->id] = $p->title;//overwrite duplicate ids in the array key } } //method 2 foreach ($interests as $int) { foreach ($int->interests as $p) { if(in_array($p->id, $array2)) continue;//if we already have that id, skip it $array2[] = $p->id; } } //testing echo '<pre>'; print_r($array1); echo '</pre>'; echo count($array1); echo '<hr>'; echo '<pre>'; print_r($array2); echo '</pre>'; echo count($array2); Above are just examples. You could even store objects in the arrays, or create a temporary WireArray and store them in there. WireArray and PageArray docs: http://processwire.com/api/arrays/ Btw, the above code will not do the counting you want. That's easily doable as well... Edit: Reading your question again, this is probably not what you want...Oh well, code stays though..

I do think this is a great project, and there are many great ideas submitted by everyone. Based on my 'past-life' experience as a tech-writer, there are two approaches to this issue. One is from the target audience point of view, the other is from the product capability point of view. Since there are numerous entries in this topic where "I do it this way..." and "I do it that way...", let's set aside the point of view of the end user, and concentrate on the functionality. To do that, each entry should have at least the following things defined: The description of what the function does, The proper syntax for its use, The parameters defined, The return values defined, A simple example of each combination, And a link to the source code. I hate to admit it, but I really like the completeness of wordpress docs... https://codex.wordpress.org/Function_Reference/add_action It makes is very easy for any skill level to quickly obtain the necessary information to move forward. I also think it would be advantageous to use ProcessWire to present this information. Eating our own dogfood, kind of thing. I would like to participate on this team too, if I may.

@Ryan: wire()->fields does not return id, name, path, url, template Fields. I think these "system" fields should be checked separately. See also https://github.com/ryancramerdesign/FieldtypeConcat/issues/6 So far I've added the following piece of code that works. $sys_fields = ['id', 'name', 'path', 'url', 'template']; foreach($sys_fields as $fname) { if(strpos($str, $fname) === false) continue; $s = $str . ' '; while(preg_match('/\b(' . $fname . '(\.[-_.a-zA-Z0-9]+)?)\b(!?)/', $s, $matches)) { $fieldName = $matches[1] . $matches[3]; $lengths[$fieldName] = strlen($fieldName); $s = str_replace($fieldName, str_repeat('#', strlen($fieldName)), $s); if(strpos($s, $fname) === false) break; } }

Just noticed your answer by accident, don't know why I didn't see it earlier. I like your idea, but I don't know if this wouldn't be confusing. You're not actually selecting posts, but rather tags, which are used in posts. $pages->find("template=posts, tags=:selected"); That's why I thought a new function could be more appropriate for this, but maybe there can be descriptive enough syntax found to be used by Pages::find. Edit: Looking at it a bit a tad longer it doesn't look as strange anymore. But thinking about the usage, would it be possible to also filter the results of such a query, like getting only tags which are categorized as "tech"? I imagine it somewhat like the sub-selectors.

@Craig: first of all thanks for this module! I did run into a small issue while using it on a SSL server. Mandrill gave me a "Unable to get local issuer SSL certificate" error and did not want to send any e-mails. It was a relatively easy fix but it does require changes in the Mandrill.php. I don't know if it should be changed in the module, but I'm posting it here for anybody else who runs headfirst into this error. 1) I downloaded the following file, renamed it to carcert.pem and placed it in the Mandrill directory. 2) I added the following code after line 72 of Mandrill.php curl_setopt($this->ch, CURLOPT_SSL_VERIFYPEER, TRUE); curl_setopt($this->ch, CURLOPT_CAINFO, __DIR__ . "/cacert.pem"); And boom! It works (well for me at least). I hope this helps somebody.

The $files variable is for accessing just about everything else about a file, but not its content. Of course the contents of files vary so much from type to type. There might not be much value in extracting the content of a binary file, but it might be a nice addition to have an easy way to extract the content of text based files. $file->url would be used, for example, for making a link to view a PDF or display an image. $file->filename is what you would want to pass to fopen. $files->path is the full disk path to the files directory for the page, eg /home/public_html/site/assets/files/1001/ Here's something else that might be useful for you to read - the difference between fopen and fread: http://www.tuxradar.com/practicalphp/8/1/3

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.

Blogs are just a collection of features around the "date-ordered content" idea. For example, the Tesla blog: http://www.teslamotors.com/blog-and-press-releases Features: Articles listed in reverse date order Articles show a thumbnail & linked title, byline, date, and tags listing. The sidebar shows features to show articles by tag, by date, and then there are some links. Individual articles show a date, title, byline, tags list, then the article body (text, images, videos), followed by comments. Sidebars for individual articles show social media sharing links. This is all (relatively easily) doable in ProcessWire with any kind of layout, so it's up to you and your client to decide what their blog will be. That's true, but remember that your client may be hoping that you will give feedback about what they are asking for. In my opinion, and according to many of my clients, a valuable part of my job is pointing out to my clients the common things that people always want later but don't think they'll ever want when they're first thinking about their site. The blog (or whatever they want to call it) is one of those things people always want at some point. In the space of three weeks one of my clients went from "we have a blog that we never update" to "please remove our blog" (with that why-did-we-ever-do-that finality) to "please put the blog back, but hide it from the front page of our site if we don't have any recent articles." Businesses almost always reach a point where they get frustrated if they don't have a place to display timely information about changes to their business. My short list of things people usually leave out, that they should really not neglect: Blog / news area Website search function Site map Privacy policy I will often let the discussion slide if the client is feeling overwhelmed with a cool new site with hundreds of features. If that's the case, we can talk about this stuff later when I have their fresh analytics data in hand. When even the most stubborn client sees a comparison of "actively blogging and sharing content" visitor stats vs. "just a brochure website" visitor stats, they tend to take a more nuanced view of the value of a website. I try to blog actively on my own websites so I know what kind of results they can expect from the additional marketing communication.

Jquestion, one good thing that has changed in ProcessWire since that post you linked to was written is that the user system is now built around pages and templates. You can add whatever fields you want to your 'user' template. This opens up a lot more possibilities that didn't exist back when that post was written. So if you want multiple users to have access to a given page, you might just want to create and add a new page reference field to the 'user' template. You might call it something like "client_page". Use 'PageListSelect' or 'PageListSelectMultiple' as the Input field type for that page field. Now when you edit a user, you can select what private page(s) they should be able to view. In your template used by that private page, you'll want to have some kind of access check in there like this: if($user->isGuest() || $user->client_page->id != $page->id) throw new WirePermissionException("You don't have access to this page"); or if a multi-page reference field: if($user->isGuest() || !$user->client_pages->has($page)) throw new WirePermissionException("You don't have access to this page"); To allow for logins by email address: if($input->post->login_submit && $input->post->email) { $email = $sanitizer->email($input->post->email); $emailUser = $users->get("email=$email"); if($emailUser->id) { $user = $session->login($emailUser->name, $input->post->pass); if($user) { echo "Login success!"; } else { echo "Login failed!"; } } else { echo "Unrecognized email address"; } }

Your first test (Test A) is what I would personally use, i.e. if($page->summary_de) { ... } Are these TinyMCE fields? I think you need to look at what's actually in the field. I have a feeling you've got some whitespace in there or something like one of these annoying TinyMCE droppings: "<p> </p>" or maybe just a carriage return or couple of spaces. Get the value out of an HTML context to see what's really in the field: echo htmlentities(var_dump($page->summary_de)); If you are dealing with possible whitespace in the field (as opposed to HTML tags or entities) then your if statement could account for that by doing this: if(trim($page->summary_de)) { ... } Don't bother with using isset() or is_null() -- those are really more useful in determining of the page's template carries those fields at all. But I don't think they are particularly useful for what you are trying to do.