ryan

This is in fact simple to do, but it does require knowing how to put it together without a CMS first. So I would suggest getting your layout up and running as a functional mockup, outside of ProcessWire or any CMS (just HTML and CSS). You could also get by with using an existing HTML page that already does these things. Lets say you've now got that in a file called home.html. With a fresh install of ProcessWire (using the included profile, not the blog one), you'd copy your home.html file to /site/templates/home.php. Now view the homepage on your site. You should see your page. If some things are broken, then that is because the links to the CSS files and other resources have changed. Typically we place our CSS files in /site/templates/styles/ and our javascript files in /site/templates/scripts/. But you can place them wherever you want. Wherever you place them, you'll want to update your /site/templates/home.php file to reference them directly. So if you had a line at the top that said this: <link rel='stylesheet' type='text/css' href='css/style.css' /> Then you'd copy everything from that old 'css' directory into /site/templates/styles/, and then update your code to say this: <link rel='stylesheet' type='text/css' href='/site/templates/styles/style.css' /> Better yet, make it say this, so that it will continue working no matter where you happen to move your site: <link rel='stylesheet' type='text/css' href='<?=$config->urls->templates?>styles/style.css?>' /> With that line above, we're asking ProcessWire's $config variable for the URL to the templates directory. Since it determines that at runtime, it'll work whether your site is running from root or a subdirectory. Once you've got your homepage looking the same as it did outside of ProcessWire, then you are good to move forward with the next step, which is to make it dynamic. This short tutorial will get you started and give you what you need to know to proceed with your magazine style blog homepage. There are also more tutorials in the Wiki that you may want to check out after covering the basics.

We could have a documentation section for this, but the reality is very few people are looking for those items. They aren't part of what one would typically use in developing a site. So we've tried to take the resources we have for processwire.com docs to focus on the more common needs. And then make sure that the less used things (like those you are talking about) are well documented in the code itself, so that you and me, and others digging deeper into the core can find and understand these things when the need comes up. Longer term, as our resources grow, more and more of this will make it into the formal documentation. You can always find a field's type by referencing $field->type. That will always produce an instance of a 'Fieldtype' derivative class. Calling $field->type->className(); will literally tell you which one. You can get an instance of the Inputfield from: $field->getInputfield($page); where $page is the page you want to get the input for. If you don't know what page, then you can just pass it a 'new NullPage()'; Note that calling $field->getInputfield($page); does instantiate the relevant Inputfield module. This means that $config->scripts and $config->styles may be populated with links to scripts/stylesheets used by the Inputfield. Though if you don't specifically use those $config vars, then it doesn't matter.

PayMill looks really nice. Doesn't look like it's available for US customers though.

You are talking about putting that URL in your browser address bar and attempting to load it, right? So far, I can't seem to reproduce that one here. Is it specific to a certain version of ProcessWire? Technically, current versions of ProcessWire shouldn't even receive that request if your htaccess is working properly. What you should get is an Apache 404 (rather than a ProcessWire 404). As a result, I'm going to guess that you are using an older version of PW (2.0?) and that you are either logged in or have debug mode enabled? Let me know if you can think of any other ways to reproduce it? Netcarver, were you able to reproduce it?

When there is a market for it, I'll be glad to have a ProcessWire VIP.

$tax = $pages->find("template=taxonomy, title=1293|1292"); I'm confused about the line above, because the 'title' is numbers like you would usually see as a page ID. Can you confirm that your page titles literally are these numbers? <img src='{$thumb}' alt='$s->description'> The above line should instead be this: <img src='$thumb->url' alt='$thumb->description' />

The ones you are most likely to encounter are translatable from /wire/core/Upload.php There is some other English text in there, but that is mostly for developer use and debugging/testing, so didn't think it needed to be translatable. Though let me know if you find something that should be.

What version of ProcessWire are you running? If it's 2.2.12 or 2.2.13 then this is line 71 of InputfieldPage.module: if(is_string($value) || is_int($value)) { In terms of environment, mine is very similar to yours, but slightly older: PHP 5.4.4 and APC 3.1.9.

Good idea for sure--thanks. Can't say as though I've ever created field names that long, so never encountered this issue. But of course we should be accounting for this. I will fix!

Try to make your columns to add up to 100% if possible. 15x6 = 90. 15x7=105. 16x6=96. 16% would get you closer to 100%. You could use 16% instead and make the first or last four in the column 17%. As for why they would be behaving differently in two different instances, that's a good question, and I'm not sure about that. It's the same code that executes regardless of output, so that's a mystery. I will have to give it a try. What are the two scenarios where you are doing this so I can reproduce most accurately?

Yes this would totally replace the ProcessPageAdd, so it would be using yours every time you clicked "new". Of course, you can make your ProcessPageAddDoolak do anything, perform any additional checks, etc.

It sounds like you've got a good idea here, but I'm not sure that I understand? Are you talking about identifying what delegate inputfield class a Page inputfield uses? The ones you mentioned (checkboxes, radios, asmselect, etc.) fit that description. But I'm not clear about why you want to retrieve that or where you are showing it. It could also be that it's the end of the work day here and all my caffeine has long worn off. I might need to come back to this and read again in the morning.

In this case I think it's because the Inputfield keeps a copy of the parent ID rather than an instance of the page. The term 'parent' already has another meaning with Inputfields as one Inputfield can be a parent of another (like a Fieldset being a parent of a Text field, or the like).

ProcessWire will do all of this, but Pete is right that you'd have to do it from the API side rather than click to setup. Probably what I will do is build some more formal workflow modules in upcoming versions of PW that do it out of the box but also give you a good starting point to modify from. Currently it's fairly trivial in ProcessWire to setup a workflow for approval of new pages to be published. But setting up the workflow for approval of modifications to already-published pages takes much more on the API code side.

Nick--Thanks for using FormBuilder. I've updated your access so you can now see the Form Builder board. See this guide in the Form Builder board which may answer some of your questions, or let me know if you have any questions.

Thanks--It looks like there are two issues there I missed. I will take a closer look and attempt to fix these tomorrow morning.

Another approach you might take is to copy ProcessPageAdd.module to /site/modules/ProcessPageAddDoolak.module. Edit the file, and rename the class to be the same too. Then go to Modules > Check for new modules, and add your version of it. Go and edit the 'Add' page (Which is here: Admin > Page > Add). Change the 'Process' field from ProcessPageAdd to ProcessPageAddDoolak. Now you have full control over the page adding process.

@doolak, it's working for me here, but I found it may depend where you are displaying the value. If you are using it for something on the admin side (where output formatting is off by default) it may not have worked. I just updated it to force the output formatting. Try it again with the latest and let me know if it works now?

@mindplay.dk: Separation of concerns, single responsibility principle, and so on -- I get it. You seem to think we're designing these things without understanding of these principles, and that couldn't be further from the truth. I'll also assume that you understand what I was stating before, that we've tried to adopt enough flexibility so that a developer can choose to adopt these principles, while still using the module interface. But we don't want to enforce that upon everyone because it would be counterproductive design. Why? There are principles, context, audience and goals. Our context is not the same as that of the Symphony framework, for example. Our audience has crossover, but is not the same. Most module cases are relatively tiny components. We have a project goal of making module development as simple and bulletproof as possible... something that might encourage web developers to take an interest in exploring their own module development. Part of that is an original design requirement of being able to share and communicate simple modules as 1 file / 1 class, when one chooses to (as many do). The ability to be super-simple and self contained like this encourages growth for the entire ProcessWire module ecosystem. We derive a lot of benefit from this, and that was the goal. It's not at the expense of the underlying principles unless you choose to make that sacrifice yourself. Don't develop your big module using the same strategy as your small module. We don't have many implied strategies for big modules and what's probably lacking most is just the documentation to explain when and why you might take one approach over another. Don't think I'm making any claims of perfection with any bit of code or design. There is always room for improvement in anything, in any project, in any system, in any file, in any class, in any method, and so on. The definition of a bad coder is someone that thinks they've got it all figured out or something is beyond improvement. I am very far from that. As most here know, I'll defend that which is worth defending and agree on things that aren't. But there's a lot more thinking behind the design than you often assume. I feel strongly about the decisions behind our current module system, and that they were the right ones. I also have an open mind. If someone proposes something better that understands not just the principles, but the context, audience and goals too, then I welcome it.

Wow this looks great Teppo! I can't wait to try this one out tomorrow.

This is due to the way strtotime() interprets dates. It interprets dates with slashes as US-style mm/dd/yy and dates with hyphens or periods as dd-mm-yy.

You might find the attached LazyCronTest.module helpful. This basically just demonstrates LazyCron in action. Install this module after LazyCron is installed, and it'll record a log entry every 5 minutes (or so) to /site/assets/logs/lazytest.txt. That's assuming the site is getting non-cached pageviews so that LazyCron gets a chance to run. LazyCronTest.module <?php class LazyCronTest extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Lazy Cron Test', 'version' => 100, 'summary' => 'Tests lazy cron by writing to a log file in /site/assets/logs/lazytest.txt', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHookAfter('LazyCron::every5Minutes', $this, 'lazyTest'); } public function lazyTest($event) { $seconds = $event->arguments[0]; $log = new FileLog($this->config->paths->logs . 'lazytest.txt'); $log->save('LazyCron 5 minute test - ' . date('Y-m-d H:i:s') . " - $seconds seconds"); } } Here's an example of the log file it generates: 2013-02-02 11:19:02:LazyCron 5 minute test - 2013-02-02 11:19:02 - 356 seconds 2013-02-02 11:24:04:LazyCron 5 minute test - 2013-02-02 11:24:04 - 302 seconds 2013-02-02 11:31:52:LazyCron 5 minute test - 2013-02-02 11:31:52 - 468 seconds 2013-02-02 11:37:22:LazyCron 5 minute test - 2013-02-02 11:37:22 - 330 seconds 2013-02-02 11:43:14:LazyCron 5 minute test - 2013-02-02 11:43:14 - 352 seconds 2013-02-02 11:49:13:LazyCron 5 minute test - 2013-02-02 11:49:13 - 359 seconds 2013-02-02 11:54:37:LazyCron 5 minute test - 2013-02-02 11:54:37 - 324 seconds 2013-02-02 12:00:07:LazyCron 5 minute test - 2013-02-02 12:00:07 - 330 seconds 2013-02-02 12:05:07:LazyCron 5 minute test - 2013-02-02 12:05:07 - 300 seconds 2013-02-02 12:12:42:LazyCron 5 minute test - 2013-02-02 12:12:42 - 455 seconds 2013-02-02 12:18:35:LazyCron 5 minute test - 2013-02-02 12:18:35 - 353 seconds 2013-02-02 12:23:37:LazyCron 5 minute test - 2013-02-02 12:23:37 - 302 seconds 2013-02-02 12:30:54:LazyCron 5 minute test - 2013-02-02 12:30:54 - 437 seconds 2013-02-02 12:36:22:LazyCron 5 minute test - 2013-02-02 12:36:22 - 328 seconds 2013-02-02 12:41:57:LazyCron 5 minute test - 2013-02-02 12:41:57 - 335 seconds 2013-02-02 12:50:48:LazyCron 5 minute test - 2013-02-02 12:50:48 - 531 seconds 2013-02-02 12:56:58:LazyCron 5 minute test - 2013-02-02 12:56:58 - 370 seconds 2013-02-02 13:03:03:LazyCron 5 minute test - 2013-02-02 13:03:03 - 365 seconds 2013-02-02 13:15:03:LazyCron 5 minute test - 2013-02-02 13:15:03 - 720 seconds 2013-02-02 13:26:03:LazyCron 5 minute test - 2013-02-02 13:26:03 - 660 seconds 2013-02-02 13:31:46:LazyCron 5 minute test - 2013-02-02 13:31:46 - 343 seconds 2013-02-02 13:37:37:LazyCron 5 minute test - 2013-02-02 13:37:37 - 351 seconds Notice how the number of elapsed seconds is always more than 5 minutes (and sometimes a lot more). That's just because it has to be triggered by a PageView. In most cases, this is okay because a lack of pageviews usually means there's nobody there to see what was updated anyway.

Twig is a nice template engine. I'd like to explore the possibilities of expanding upon what porl started with that module sometime. Though ProcessWire will always be based on a PHP API, but I'd like us to have a simple integration method for supporting other template engines for the people that want them.

Awesome work Wanze! Thanks for posting it. I'm also thrilled to see the awesome things people are doing with the blog profile as a base.

Soma, I'm not totally sure I understand just because I've not seen buttons look like that before. I could probably figure it out by digging a little deeper in the code, but I'm trying to get through a large queue of messages in a short amount of time (they dont' give me much on the weekend!). If there's a code change you think would be worthwhile in the core CSS, let me know what to change (post code here or pull request, etc), and I'll make it.