Leaderboard
Popular Content
Showing content with the highest reputation on 09/28/2014 in all areas
-
Hey, this is a website I finished some months ago. The website is for a christian "St. Johannis" church close to where I live and is managed by my mother (that's where my "my mother should be able to use this" comparisons are from ). I really clean and minimalistic but a lot better than the old design. Trust me
6 points -
Logic is too broad a term. There is presentational logic and there is application logic. IMO the logic you want to keep out of the main template is application logic, not presentational logic. If there is presentational logic that applies to most pages in the site, then I really prefer to have it in the main template, or at least include()'d from the main template. It comes down to what's going to simplest to maintain long term. If something presentational needs to be manipulatable by other templates, then of course it should go in it's own placeholder variable. But if it's not, then delaying that output or moving it somewhere else is just more overhead and things to keep track of. This is of course just fine, and everyone's got different methods that work best for them. But I would also suggest that the more markup you can keep in your main template (that's common to most pages) then easier it is to maintain over time. Easy to maintain means different things to different people, so I should qualify that to me "easy to maintain" is when the site-wide markup is in fewer places, fewer files to update, etc. I don't think the holy grail is necessarily eliminating html tags from your template files. That's what I did with the blog profile, sticking to an MVC approach. But I don't find it as maintainable as default site profile intermediate method (maybe for a team, but not for an individual developer). Further, and somewhat to my disappointment, I think most find the blog profile (sticking to an MVC approach) difficult to understand. The fact is that this approach means more files, more things to keep track of. It's the right solution for some cases, but it's no holy grail. I think instead the holy grail is KISS + DRY (keep it simple stupid + do not repeat yourself). If you've got markup going in a template file where the same markup is going in another template file, then put it in a shared function, include file, template/view file or a class/hook or something (I prefer functions myself). If you've got to change something, make sure you only have to change it on 1 place. The end result ends up being most template files have little or no markup, not unlike the MVC blog profile… but a whole lot easier to understand and maintain– you've KISS'd it, minimizing the number of places where markup appears and not adding extra unnecessary overhead and files. The benefits of going further MVC become apparent when you work in a team where the concerns are split along the same lines as the files. In that case, more files is beneficial. The front-end markup girl/guy focuses purely on the view files, and the back-end developer focuses purely on application logic. But if it's not a team project like that, and isn't going to be, then following that approach is kind of like trying to avoid stepping on the seams in a tile floor as you walk across it… Think of "main" as meaning "main" (like primary), not "all". One example of different layouts can be seen in the intermediate profile's _main.php where it adds a has-sidebar class to the body tag when a $sidebar variable has something in it. But there's no requirement that _main.php be used by every template file. You can disable the $config->appendTemplateFile in your /site/config.php and include your own, like Martijn outlined above. Or you can edit your template in the admin: Setup > Templates > [your-template] > Files. Check the box to disable auto-inclusion of _main.php, or specify what file you want it to include instead.5 points
-
For me there's too much logic in the main template in the example ryan has given. (if statements) I prefer to build the variable Markup in the template. Not in the _main.php <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title><?= $page->headline; ?></title> </head> <body> <header><?= $header; ?></header> <nav><?= $nav; ?></nav> <div id='content'> <?= $page->content; ?> <?= $page->sidebar; ?> </div> <footer><?= $footer; ?></footer> </body> </html> I almost always use this approach, except that I do not use the automatic prepend and append functions from ProcessWire. I use a include(./_init.inc) and a include(./_main.inc) in the template file. template file +---------------------+ |include(./init.php); | | | |$title = "<h1>...etc.| |$content = "<div>... | | | | | | | |include(./main.php); | <-- could be changed, maybe we want to include ./special-main.php +---------------------+ When I need a major change how the page should look like, I could decide to include an other 'view' page in the bottom.5 points
-
The idea behind this concept is that _main.php would NOT contain any logic at all. The only thing that _main.php will do is echo out the variables & markup. Default variables are created in the _init, if needed, those variables can be overwritten in the template. +----------+ | _init | $title = "<h1>$page->title</h1>"; | | $content = "<div class='seventy-five_percent_wide'>$page->body</div>"; | | $sidebar = "<div class='twenty-five_percent_wide'>$page->sidebar</div>"; | | | | +----------+ | +----------+ | template | Contains Logic. | | | | $title = "<h2>$page->title</h2>"; | | $content = "<div class='fifty_percent_wide'>$page->body</div>"; | | $sidebar = "<div class='fifty_percent_percent_wide'>$page->sidebar</div>"; +----------+ | +----------+ | _main | This file only outputs Markup. There's no 'logic' here (read no if statements and stuff) | | And the variables ($title, $content & $sidebar) will will be echoed here. | | | | | | +----------+ In the code block, you can see that the variables $title, $content & $sidebar are first setup in _init. We see the following: The title is a <h1> header. The content is markup with a column of 75% wide The sidebar is markup with a column of 75% wide This are nice defaults as most of our pages are structured like this. When we want these defaults, the template file can be empty. But if we need a page with 2 columns equal wide and have a H2 header instead of the H1, we could overwrite the variables in the template file. As you could see in the code block, we overwrite $title, $content & $sidebar. The main file could simply look like this: <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title><?= $page->headline; ?></title> </head> <body> <?= $page->title; ?> <?= $page->content; ?> <?= $page->sidebar; ?> </body> </html>5 points
-
We just created a complete coporate design to the german coach Priv.-Doz. Dr. med. Michael Huber. The corresponing website is as always based on the beautifu Processwire. Feel free to check out this tiny responsive website under http://www.huber-idc.ch We are looking forward to your feedback.
4 points
-
I can a few different options here. Use the attached module which uses some jQuery to force the description field open - seems to work fine and I don't think there will be any side effects with it affecting other fields, but you can tweak the jQuery if needed. You could make use of Martijn's new module http://modules.processwire.com/modules/admin-custom-files/ and use the code from the attached .js file. Figure out how to change the status of the collapsed state with a before hook ProcessField::buildEditFormBasics - you'll see I tried a hack - in the attached module, my first approach was not with the associated js file, but instead of the after hook, I used a before hook and used the commented code to make sure the description field wasn't blank. This was ugly, but I couldn't figure out how to change the collapsed status properly in this case - sure I am missing something obvious, but only had a few minutes this morning to look at this. FieldExpandDescription.zip4 points
-
Hey, I really spend a lot of time to figure out how to add additional options to a config page (which are generated with the function "getConfigInputfields"). I use an autoload module for this, At first we need to create the module: <?php class ExampleModule extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'ExampleModule', 'summary' => 'Bla bla', 'version' => 1, 'autoload' => true ); } // the rest of the code should be here } ?> Then we add the init function to it which includes a hook into the config page page we want to extend. In my case it is the option page of the InputfieldDatetime: public function init() { $this->addHook('InputfieldDatetime::getConfigInputfields', $this, 'addConfig'); } The last step is of course the "addConfig" function: public function addConfig(HookEvent $event) { // get the field instance used by the config form $field = $event->object; // TRICKY PART: use it's name to get it's saved values $data = $this->fields->get($field->name)->data; // add a new field with the saved value to the form $fields = $event->return; $field = $this->modules->get("InputfieldCheckbox"); $field->name = "useSimpleDate"; $field->label = "Use \"Simple Date\"?"; $field->checked = ((@$data['useSimpleDate']) ?: 0); $fields->add($field); // return the new config form $event->return = $fields; } The only really tricky part is to get the value. In this case it works like this. In other cases you may have to get the modules config.4 points
-
The vital thing for you to do is to construct your files in such a way as you find easy to maintain and work with. For myself, I take a pretty non-techy approach, which probably means it is far from the best. But it works for my sort of head. I am a composer and when I compose music I start with a melody and then I build the rest of the arrangement around it on different tracks - different parts of the score. The main melody is the constant. I write the same way. So with ProcessWire I do the same thing. I start with a huge great DIV that will contain most of my look and feel. In the middle of that I will put my main theme. "Hello, this is my website" Then I add the arrangement around it - a header, footer information, and so on. When it comes to making changes in the arrangement, I will have a functions file with lots of goodies - listing of child pages, news listing, galleries and so on. These get pulled in by the conductor when and if needed. So, at the end of the day, most of my pages are probably based on one template file, with other files included - head, foot, functions, end page scripts, whatever. I know having a head and foot is terribly old fashioned, but it works fine for me. And if I do need other templates that are working in radically different ways, then I just copy and paste my includes over and off I go again. In a way, looking at any existing profile and using it as a starting point can be confusing and misleading. ProcessWire doesn't care which way you work, after all. So, install the blank template and just get writing some good old fashioned html. There you go - a sunny Sunday afternoon magazine style comment. Joss4 points
-
Hi MuchDev, by default we prefer to bump up older posts then to create new ones. This way things that are close together are also stored close together and that makes it easier for followers (for us all). But no problem here. And, - if you want that people has a good chance to help you with your problem, you should provide as many useful information as possible. (focus is on useful == quality over quantity). Ah, found a post that is titled: Lots of images to resize, timeout in frontend I can ask you mainly the same things here: "Maximum execution time exeeded" doesn't say much. I think it has to do more with your server than with the Imagesizer because I know many sites with many thousand images where it doesn't run into this. Also mormally it doesn't matter if you have a million images on a site but how many images are belonging to a single page. I have running sites with single pages that have 300+ images that needs to be rendered into 4 derivatives each at first page view (1200 derivatives in less then 30 secondes). What are the most and/or the average number of images per page in your site? How many derivatives do you need? How big / large are your original images in MB and in pixels (maybe you have some with to many MegaBytes laying around?). You can set a maximum-width and -height in the image fields to downsize them directly on upload to for example 800px or whatever you prefer. Does the server have enough memory to work with? How many? Recommended is 128M or better 256M for large image sites. Are you on a shared host? Is PHP running as apache module or as cgi? If you read that other thread you will find a solution to render your derivatives directly on upload.4 points
-
@horst, don't know if it does or not. Here's another possible starting point though: set_time_limit() Update1: Looks like you might be right according to this on Stack Overflow. @nico, there are some apache config options to check in there too. Update2: Added the timeouts to DiagnosePhp.module as well.3 points
-
The great thing I like about PW is that you never are forced to do something in a particular way on the front-end. You actually have many choices on how your website is gonna be structured. I haven't found any other platform that gives you that amount of freedom to develop your website or application. That can lead to problems, because people are used to being told (forced) to develop or create a certain way. Once you start working with PW, you are left to decide for yourself. I believe that can be intimidating to some, because they never had the freedom to choose before. Over time, the light goes on in their head when they finally understand and realize that what gets created is whatever they want to be created. I believe it's very hard to settle upon the fact that you can design or develop with no limits to your creativity. PW is constantly improving with documentation and videos (and that is wonderful). The real truth is that PW is such an open platform that we could never cover or teach all the different possible ways of working with it. There really is no right or correct way to do things. If a certain way works for you -- that's great. If you change your mind and want to do it another way --- you can. What you ultimately end up with is a website based on your needs, crafted based on what you know how to do.3 points
-
It's all kinds of incredible. It's like... everything I can think of, Ryan has thought of it first, and in a brilliant, flexible way. What I'm noticing is that I'll see all these extra options and menus hidden behind collapsed fields and wonder what they are. Then, the next minute you know, it's like... "hey! that's exactly the functionality I'm looking for!". I mean... I was looking at that input option the other day "Parent of selectable page(s)". Repeating the words in me head, thinking to myself... man, that sounds cryptic. I wonder what that's for. And now today, when I'm trying to get things to work in a certain way, I come across that field again and it all makes perfect sense, perfectly and intuitively laid out. But... and this is the thing that's unique to ProcessWire... not in your face, but there to be easily found when you need it. I'm finding that to be the learning pattern with ProcessWire... first you have to conceive of the logic order of what it is you want to do, then go discover if there is a built in way of doing it... 9/10 there is! Much, much respect to the author.3 points
-
Okay, the penny has dropped. ProcessWire is AMAZING.3 points
-
@horst: Done for set_time_limit(). DiagnosePhp.module now at v0.0.42 points
-
@nico, I'll add those lines. Update: Done, added to DiagnosePhp.module.2 points
-
This is by design. and everyone can replicate it by simply setting the amount of memory way to small for such large images on his server. So, the error message in the first example isn't that lucky because you see the error from the derivative image (admin thumbnail 0x100) what could not be created from the way to large original image that should be scaled down to a max-size. If you have a look into the original image (open it in a simple plain text editor!) you will see that it contains something like: whereas the 0x100 thumb contains: @Ryan: Maybe we need to display the error from original image too so that it is more clear what was going on? So, but in your second example you can already read it by yourself: not enough memory to load/resize Imagerendering with the GD-lib needs minimum ram memory 2 - 2.5 times of the uncompressed image! If you load to large images into memory GD/PHP crashes with a not catchable fatal error. PW since version 2.5 does look ahead to available memory at runtime before loading images into memory. This way it saves you from crashes! I like how it works. Great job @Ryan! Simple calculation example with your image: width x height x colorchannels = memory bytes 4.608 x 3.456 x 3 = 47.775.744 - just to load one of those images into memory (togehther with rest of PW) you need 60MB ram! - and if you want to manipulate / resize it you need 47.775.774 x 2.3 = 109.884.211. Do you have a minimum of 128MB memory available for PHP? No, you need to bump it up. I recommend setting it higher in available server configuration panels, php.ini file or in the .htaccess: <IfModule mod_php5.c> php_value memory_limit 256M </IfModule> But you should not transmit images 4 times larger than the largest needed display size. (Denk an unsere Umwelt und an unsere Kinder die diese auch noch brauchen!) g-translate: (Remember our environment and our children also need this yet)2 points
-
<div id='main'> <!-- main content --> <?php echo $content; ?> <!-- sidebar content --> <?php echo $sidebar; ?> </div> this would be the main.php and the basic logic would be in the _init.php like this: // if the current page has a populated 'sidebar' field, then print it, // otherwise print the sidebar from the homepage $homepage = $pages->get('/'); if($page->sidebar) echo '<div class="mydiv">'.$page->sidebar.'</div>'; else echo '<div class="mydiv">'.$homepage->sidebar.'</div>'; and in a pagetemplate you could overwrite the $sidebar or extend it! so all logic is in the _init.php (basic output) or the template for the pagetype! example special-page.php //overwrite it $sibebar = $page->specialField; //extend it $sidebar .=$page->specialField; just written fast written in the browser....2 points
-
Russell, Have a read here: http://processwire.com/docs/tutorials/how-to-structure-your-template-files/page4 Also, in the tutorial you referred to, it says: So, there will be cases where you might need more than one 'main.inc'....of course they would have different names. But, the idea is to try and reduce these to as few as possible so that you can reuse code/markup as much as you can....2 points
-
this template approach is more like one step further to a template engine (or even call it a template engine)... You complete separete the logic from the code. the advantage could be that a desinger could use the given vars $title, $content, $sidebar and change the main layout with this vars.....but you are right it is not the reall holy grail....since some html tags in the pagetemplates, too..... it's just a other logic behind - you could choose what fits for you best. some like to have split in logical parts like header - content - footer - and some wanna have the main logic together and the content logic separate - it's up to you - regards mr-fan (Martijn was faster and more proper )2 points
-
Often times, creating a side project is first and foremost scratching your own itch Or to start differently: Currently, I'm developing a site where I need CKeditor (and later jQueryUI Datepicker) outside of the admin, in frontend. I searched Google and the forums and found an approach to follow - but during the research the site laravel-recipes.com came into my mind (since I'm currently also looking into this framework). It's content consists of small, spot-on bits of information, for example: http://laravel-recipes.com/recipes/269 Just to think out loudly here, wouldn't it be nice to have a ProcessWire counterpart of such a site? processwire-recipes.com for example? Target group: Developers, from beginner to advanced Difference to these forums: Stripping the discussion part, concentrating on the info; and if done properly: bypassing the mediocre forum search, better tagging Difference to the official tutorial section: Focusing on not creating a whole site, but modular parts of it. Single solutions. For example: First child redirects (shameless plug, but this is the format of information pieces I'm having in mind) Difference to the API documentation: Situation-based ("I need this and that") instead of architecture-based Laravel.io (forum), laravel.com (official, and doc) and laravel-recipies.com possibly prove that these type of sites can coexist in a framework ecosystem, so I guess a recipes site would not cannibalize this forum here nor the doc section. A recipe site like this would live and die with its content, of course. I would be ready to share all the small pieces of information I encounter that would make a good "recipe". But that alone wouldn't be enough so this project won't survive without contribution of the community. What's your opinion on this? Yea or nay? Update: ...it just took, erm, nearly three months,... but here it is: https://processwire-recipes.com/1 point
-
This is a simple module to prevent guest users and search engines from accessing to your site. Primarily it is designed for use during site development. Modules directory: http://modules.processwire.com/modules/protected-mode/ Github: https://github.com/adrianbj/ProtectedMode Install and check the "Protected Mode" checkbox Create a user with only the guest role and give the login details to your clients/testers. Of course existing admin users can use their personal logins still. There are some similarities with Pete's excellent Maintenance Mode module, but the reason I built this, rather than using Maintenance Mode is: I didn't want the "Maintenance Mode" badge showing up on the site since this is for development before a site has ever been live and I didn't want the client seeing that badge. I didn't want users redirected to the PW login page because I didn't want visitors to see the PW login page. I know the module has the option to redirect to a custom page, which you could use to make a front-end login form, but that seemed more complex than I needed (and I think other PW devs might also need). Because of the way this module replaces Page::render with the login form, visitors can be sent to any page on the site, and once they login that page will reload with its full content - no messing around finding the page again, and no need for sending page ids through the login process to redirect back. This module also lets you configure the message that is displayed along with the login form, and also apply some css to style the login form. Hope you guys find it useful.1 point
-
only 30 images of max 1 MB or max 1200px isn't much. I have 300 images at 800px per page on one site that works fast and fine. The only thing that rings alert here is the fcgi mode. I don't have enough experience with server adminstration, (in fact I don't have any ) but I have seen that servers configured as fcgi can have disadvantages that results in slow execution. (has to do something with that system threads need to wait for their rights to start, they are somehow queued and delayed) So, I believe an apache with fcgi could be tweaked to also run fast, but I don't know how. In the opposite I never have seen those problems when php is running as apache_module.1 point
-
Solved it with horst's work around. It still bothers me though... <?php $filepage = $pages->get('1012'); $filepage->of(false); $filepage->files->add($config->paths->root.'tmp/file.pdf'); $filepage->save(); ?>1 point
-
Yeah I think you've hit the nail on the head. Being a programmer, but not a web developer or designer, I'm left with the freedom to do what I want, but the dilemma of not know how to go about it from scratch. Other CMS's give you no freedom, but a very simple ruleset to follow if you want to make canned changes within their frameworks.1 point
-
I have uploaded a file of 42MB to my site via the PW admin to a file field. It tooks 8 minutes for successfull upload. My settings from php.ini on this site are: file_uploads On max_file_uploads 20 // this I have found too, sounds like max number for simultaneous uploads upload_max_filesize 200M upload_tmp_dir post_max_size 240M max_input_time 60 // has nothing to do with time used for fileupload!! memory_limit 256M enable_post_data_reading On // this I have found too, don't know what it mean max_input_time is set to 60 seconds, so this is not relevant for fileuploads I think. ------ PS: @KentBrockman: thanks for the continued support.1 point
-
Thank you for your post, this is really helpful information, I did see that post before but missed what you guys were talking about when I read it initially. Good to know about the etiquette, I always feel like I’m doing it wrong J. Sorry for the limited info also I supplied all I could see out of that very vague error that the server gave me. I was actually surprised how vague the error was, I’m used to seeing errors that are considerably more detailed and not in red . After staring at the error and reading your previous posts on the other page it is now a bit more obvious that my problem is due to a timeout issue with the server running into its 30 sec time limit for processing a page the first time. My images are limited by their current web guy to 1200px wide proportionately, therefor the largest image that we have so far is around 900kb-1mb. Most pages have a 30 item limit in the get and are then paginated. The server itself is a vps through bluehost, so the specs are : Dual Core Opteron 6376 (2.2hgz) 512k cache Memory: 1901912k/2097140k available (5330k kernel code, 408k absent, 194820k reserved, 7009k data, 1280k init) Centos 6.5 As far as the deeper settings I must first admit that this is my first foray into linux server administration, but I did some digging and my php handler is set to fcgi. Everything came pre-installed and configured when I set the server up initially. Is this something that I could view through WHM? That is really a cool tweak for the image module I didn't understand that the function was forcing the creation of derivative images, but as this is paid hosting I feel wary of increasing the image footprint and have to force the customer to pay for extra storage, I foresee this site ending up with around 30-40,000 items / images + derivatives. All in all, it looks like I may need you to help me to help you so you can help me .1 point
-
@Peter, You should pass the values from $page->product through a url sanitizer. If there are any spaces in the product field you'll get a dud url doing it like that. $url = wire()->sanitizer->url($page->product); You could pass the price field through the sanitizer too - no harm in that.1 point
-
I think this isn't relevant for uploads, but also remember that there is something called like max-input-time in the php.ini? EDIT: no, this (max_input_time) is also not relevant: max_execution_time = 30 ; Maximum execution time of each script, in seconds max_input_time = 60 ; Maximum amount of time each script may spend parsing request data memory_limit = 256M ; Maximum amount of memory a script may consume (128MB) file_uploads = On post_max_size = 240M upload_max_filesize = 200M upload_tmp_dir =1 point
-
Nico, is the upload taking longer than the max runtime of PHP scripts?1 point
-
I wouldn't use the site/assets/files/id/ folder, you should create / use a temp folder besides site and wire: |-site |-temp |-wire and then I would try to add them via API: $targetpage->filefield->add('/fullpath/to/temp/basename.ext'); // or is it called ->addfile()? PS: if you would use a site/assets/files/id/ folder, it would create a basename-1.ext file I believe. (but not sure)1 point
-
Perfect! I chose option one. Thank you!1 point
-
It works perfectly with files up to 1.5mb. Maxfile size is by 40mb at the moment. I'll try your code. Thanks so far! (I'm going to install ProcessDiagnostics to check that ) Edit: Can't find it in ProcessDiagnostics. Would be a good thing to add I think.1 point
-
I am not an expert either, but you can try this solution from clever people at stackoverflow. In short, "try 127.0.0.1 as the server name instead of localhost".1 point
-
I guess two kinds of sortings for recipes could be useful: Tags/Keywords (like Bolt snippets: e.g. https://snippets.bolt.cm/s/gsudt) A greater narrative, recipes grouped together into e.g. dealing with core modules, building a multilanguage site, wrangling media and so on. Inspired by the table of contents of http://laravel-recipes.com/contents1 point
-
just forked it and added some recipes....later i will add more and separate them in tags/groups https://github.com/mr-fan/concept i think a tag sorting would make sense here, too and some more sorting.....since we wanna better/faster availability for the snippets like in this forum.....so only date and alphabetical wouldn't be enough? But the basic concept is quite easy and easy usually the best equal for beginners or pros....1 point
-
Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.1 point
-
I think more direct workflow would be from template - possibility to create a new field and attach it directly to a template. I mean you pretty much always want to order the field, so you need to be on template view anyways.1 point
-
If you stick with the way you are doing it now, giving each checkbox field it's own 'name' attribute, then you would just need to update your $form array to include them, like the additional 'Hats' entry below: $form = array( 'contact_name' => $sanitizer->text($input->post->contact_name), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), 'Hats' => ($input->post->Hats ? 'Yes' : 'No') ); Your <input> tag should also read like this: $checked = array(); $checked['Hats'] = ($form['hats'] === 'Yes' ? 'checked' : ''); … <input type='checkbox' id='Hats' name='Hats' value='1' $checked[Hats]> However, I think a better way to approach all of the above is to use just one $products variable to account for all of them. $products = array('Hats', 'Gloves', 'Mens', 'Bags', 'Scarves', 'Clothing'); $form = array( 'contact_name' => $sanitizer->text($input->post->contact_name), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), 'products' => array() // make it an empty array ); // sanitize like this if($input->post->products) foreach($input->post->products as $product) { // here we are just ensuring submitted products are in fact valid if(in_array($product, $products)) $form['products'][] = $product; // add product } // output the checkboxes like this: foreach($products as $product) { $checked = in_array($product, $form['products']) ? "checked" : ''; echo "<label><input type='checkbox' name='products[]' value='$product' $checked> $product</label><br>"; } The above may look longer, but keep in mind it's replacing the entire checkboxes input and output, while giving you more flexibility. Adding a new product is just a matter of adding it to the $products array at the top. When you generate your email, you'll want to detect the array so that the email has the product names rather than the text "array()": foreach($form as $key => $value) { if($key == 'products') $value = implode(', ', $value); // make it a CSV string $message .= "$key: $value\n"; }1 point
