kongondo

Hi Mosravo, Welcome to PW! That's right. You can use any HTML, whatever, you like with ProcessWire and style it as you wish. The Site Profiles you talk about are sort of something of convenience, ready made for those who wish to use them. And even then, once you've installed them you can bend them left right or centre as you wish. In other words, there are no ProcessWire themes..

As a rule of thumb...anything that is submitted/sent via a form and that will be used to query your database should be sanitized and/or validated whether or not you put it there in the first place; the DOM can be manipulated... I don't know what dynamic sanitizing is....

Thanks for sharing Gayan! It would be good to explicitly state in your install instructions that Site Profiles can only be installed on 'new' sites (newbie alert ). I know it is implicit here 'Please take a copy of the [latest ProcessWire]' but it could be clearer Edited to request clearer instructions...

<off-topic>LoL. Guys please, I'm gonna need a bigger hat soon if this carries on </off-topic>

If you want to use the values sent as.. email value use $sanitizer->email name for a ProcessWire page that you don't care if it has upper case letters use $sanitizer->name. Name is used to build your url so this will be my-Upper-Case-URL name for ProcessWire page that is more friendly $sanitizer->pageName so url will be my-lower-case-url a valid selector string use $sanitizer->selectorValue a valid string for a ProcesWire page $sanitizer->text etc Unless you are a developer (and even then this is rare) you will not need $sanitizer->fieldName or $sanitizer->selectorField. Note, you are not limited to using the above according to my examples. For your own needs, you may want a string to be cleaned to remove dashes, etc. So, you can use $sanitizer->name in that case... If the above still doesn't make sense...I'll eat my hat

I have never worked in a multilingual ProcessWire environment so I hope my answer doesn't seem foolish Output strings are all translatable. See posts above; someone has worked on/produced German translations. There's maybe 1 or two texts not yet made translatable but will do a final check soon... Glad you like the module

I don't know who Kokondo is but you sanitize according to the values you want. There's sanitizing for url friendly names, for texts, for emails, etc.... It's all documented here: http://processwire.com/api/variables/sanitizer/ The only thing you don't sanitize are passwords. BUT...you validate that they only contain characters you have pre-determined...Otherwise, if you sanitize passwords, you might change them and your users may not be able to log in...

It depends on the type of value sent from the drop down. If it is an integer you typecast/sanitize it like so... $cleanValue = (int) $input->post->name_of_select_value_field_sent;//note: name of the dropdown input field! If it is a text you sanitize it first... $cleanValue = $sanitizer->text($input->post->name_of_select_value_field_sent);//this is the name of the input! Then you check if $cleanValue is in your array of clean values... if(in_array($cleanValue, $arrayCleanValues))// blah blah

Nico In this post https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ I attempt to explain various approaches for handling categorisation....Maybe it will help...

Hi Sendxt, Welcome to ProcessWire and the Forums! I am in a bit of a hurry. See solution here..https://processwire.com/talk/topic/6243-images-in-a-repeater-field/ Key thing to remember is that behind the scenes repeaters are also pages and need to be treated as such...hence you may also need to foreach (loop) through them....Normally, this would require nested foreachs...if the images are also an array.. foreach ($page->my_repeater_field as $f) //$f is the repeater....you need to loop through it if you have multiple images inside it... foreach ($f->images as $image)//do stuff....

Yes..it is a very well thought-out system ...If fields were only available for a particular template, then they wouldn't be reusable. That would mean creating, e.g. a textfield for template A and a different textfield for template B, etc....a waste of resources . And yes, you can add any sorts of fields to any template as long as you create those fields first. Fields will not automatically be added to any template unless you specify the field as 'Global'

Thanks for posting. I see nowhere on that whole thread any instruction to put anything in "/wire/modules/". Ryan especially wouldn't say that ....What the post says, in short, is that if you want a menu link to appear somewhere in the main Admin menu, just create a new child page of Admin. It will automatically be listed up there with 'Setup', 'Pages', etc. Of course, that link leads somewhere...e.g. a ProcessModule. In that case, the page will normally be created within your ProcessModule on install and not you doing it manually...

Yes. Everything custom should go to /site/xxxx. This way, on updating ProcessWire, nothing gets overwritten (i.e. /wire/ is overwritten on updating PW). Just curious, what custom module is that that was placed in /wire/modules?

Welcome to ProcessWire Jordan!

Oops, you also need to show the form if nothing has been sent ...so do an || as well...or similar...Ideally, you need to show some error and the form if a wrong password was sent versus when no password was input at all..

Of course, there's always the simple typo maybe? Edit: Duh to self!!! You have to use isset() to first check if a variable has been sent $pass = $input->post->awesome_password; if (isset($pass) && $pass != $page->page_password || !$pass)//....show form etc...

Edit: Deleted... I think some of my explanation above is wrong; it's late, am tired! ...

I had a nice tutorial somewhere about creating virtual hosts...can't find it now. I even did this some time back. It's all about editing your PC's host file (to serve your fake hosts) plus your appache httpd.conf, if I remember correctly...I use XAMMP with a customised start screen

Thanks! I think there are a few remaining strings that need to be made translatable as well like the 'No' and 'Yes' for published posts. I'll get to them later.

Yes; this is now (or soon will be) resolved in the core https://github.com/ryancramerdesign/ProcessWire/issues/432 Not sure if it has been committed yet...

Update: Blog version 1.2 Read below before updating. For new installs, proceed as normal ------------------------------------- Changelog TL:DR: Comments visibility settings + Posts' Bulk Actions + Update Script Comments Comments visibility can be controlled 'globally' as well as on a 'per post' basis Default is that comments and comment form are visible. You do not need to specify this setting; it just applies A post's comments SPECIFIED visibility overrides the global setting except for one case (see below). Post Comments Settings are set via a page select on a Post's page (also in 'Settings' tab in Blog Dashboard - see below) No selection: Default [comments and comments form will be shown] Always Show Comments: This will enforce overriding of global setting (e.g. Disable Comments) Disable New Comments: Will show old comments but not the comments form; visitors will not be able to submit new comments & message 'Comments closed for this post' will be shown. Disable Comments: Will neither show old comments nor the comments form; visitors will not be able to submit new comments & will see message 'Comments not allowed for this post'. Old comments WILL NOT be deleted . Global Comments Settings are set via a page select on the Comments page (in Dashboard as well). Settings here DO NOT override a Post's Comments settings WHERE A SELECTION has been made (i.e. if NOT empty). No selection: Default [comments and comments form will be shown] Disable New Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Disable Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Global Maximum comments allowed per post. If any number > 0 is specified in this new setting, IRRESPECTIVE of a Post's comments settings, if a post's comments is greater than the maximum set here, then 'Disable New Comments' will kick in. So, this takes precedence. Note: If you are logged in as superuser, even PENDING and SPAM comments are counted; so, the Global Maximum may be 'temporarily reached', if that makes sense Recap of comments visibility, in order of descending priority: 1. Global Maximum comments allowed for posts (/blog/comments/) 2. Any comment visibility SPECIFIED on a post (i.e. not empty) (/blog/posts/your-post/) 3. Any Global comment visibility SPECIFIED on comments page (/blog/comments/) 4. Default. 'Settings' Tab You can also set both the Global comments visibility and the Global Maximum comments allowed per post on this tab. The current setting will always be selected in the input field. Note: A blank Global comments visibility means no setting specified . So, if you want to change to 'no global setting specified', just select a blank and save [equivalent to deselecting a page select] (hope this makes sense). Note: Where no Global Maximum comments is set (i.e. blank), saving in the 'Settings' Tab's General Settings will subsequently show a '0' [zero]. This is equivalent to a blank, so not to worry Bulk Actions Introducing Bulk Actions for the Posts Tab! Make bulk changes to posts: Unpublish/Publish Comments visibility (as specified above for Posts' Comments visibility). In this case, also a 'Default Comments View' selection available. This is the equivalent of the 'no selection' specified in page selection field above. Trash Delete (note: no warning given before delete; careful with this one!) New column in Posts' Table also shows currently specified Comments visibility for each post. 'Default' means no selection made. Other - Some code clean-up. - See blog-side-bar.inc issue below. UPDATING I have written an update script (attached) that will add the new features in Blog 1.2 (2 fields, 1 template, 3 pages, 2 page updates, etc.). I have thoroughly tested the script. However, try this first on a test/non-essential install! If everything works, you can use it on your live environment Note: This assumes you haven't changed the native Blog paths and page names. Otherwise, it won't work properly. It won't corrupt any data but may just not install some stuff Note: You will still need to update the module as normal in your PW admin! Above is just to save you manually creating the extra fields, etc. To update: # Copy and paste the contents of blog-upgrade-version1-2.txt at the very top of one of your template files. Save the template file. # The script will only run if you are logged in as a superuser so other users won't know what's happening. # View a page using the template file you've just amended. The new fields, template and pages will be created. # Reverse the changes to your template file and save. # Update Blog via PW Admin as usual (to version 1.2) # Copy blog.css to /site/templates/css/. blog-upgrade-version1-2.txt If you are using the blog-side-bar.inc you might want to make/note the following changes. This only affects existing Blog installs! (not new ones) There was a missing <br> tag + $item->date instead of $item->blog_date. This will ensure Recent Comments widget also show the Post's date. If you are using the code from this file, you can make the following changes: OLD: $date = $blogOut->formatDate($item->date); $out .= "<li><span class='date'>$date</span> <a href='{$item->url}'>{$item->title}</a></li>"; NEW: $date = $blogOut->formatDate($item->blog_date); $out .= "<li><span class='date'>" . $date. "</span><br> <a href='{$item->url}'>{$item->title}</a></li>"; In addition, the code has now been changed not to show 'recent posts widget' on the blog home page. @Adrian idea, thanks! Screens Happy blogging!

Hi FuturShoc. Glad you like the module. I thought about this a lot, even with the /site/blog/.... URL, where others would prefer /site/my-awesome-post/...but decided to leave it to the user (for now at least...), if they so wish, to manipulate the URL segments... UPDATE: Feature now available in Blog version 2

Yep, what Martijn said or read here from the Reiska himself https://processwire.com/talk/topic/163-images-and-thumbnails/?p=1160

Good catch Antti!

Try $image->of(true); just before resizing...