ryan

I've added a feature on the 2.4 dev branch that several people have asked for in the past: 1-step adding of pages. To enable it: edit the template used by the parent where you want to support 1-step adding of children. In the 'Family' tab, in Allowed template(s) for Children choose the single template you want to be used for children. Once you do that, you'll see a new box appear below it, titled Name format for children. You can enter any text that you want here, and the page names will use it. If the name causes a collision with another page, then an incrementing number will be appended. You can also enter just the word title if you want it to base your page name on the title field (when you later populate it), or you can enter a PHP date format to base the page name on the current date and/or time. More details This screenshot explains it all. Look at the "Allowed template(s) for children" field and the "Name format for children" field. There are drawbacks to 1-step adding of pages, which is the main reason we've not supported this in the past. The biggest drawback is that you can end up with a unused pages due to accidental clicks on an add page button. To reduce this problem ProcessWire assigns a temporary status to pages created this way (Page::statusTemp) that gets removed as soon as you save it the first time. Pages that remain statusTemp will be automatically moved to the trash after having that status for 1+ days. Of course, pages created this way also have Unpublished status, so they aren't going to be showing up on the front-end of your site until you publish them (like any other page you create). The second drawback is that you are skipping over the page naming step, so pages have to be named automatically (which is what the Name Format you specified is for). Of course, you can easily change the name to whatever you'd like from the 'Settings' tab of any page. I've removed that drawback by adding the "title" option. When used, it populates your page with a temporary name and then re-populates it with your page title when you save. For most situations, you'll probably still want to stick with the 2-step page adding process. But for situations where you'd find it worthwhile to have 1-step, you now have the option.

Alan, you can delete the ckeditor-4.3.0 directory as that's just an old version that's no longer in the module's source code. I recall seeing this issue in older versions when pasting copy, but haven't seen it in any recent versions. I'd be curious to know what your CKEditor settings are. Check that you've got ACF enabled in your CKE field settings, which should filter out that kind of stuff. You might also want to enable HTML Purifier as well, which would clean out that kind of stuff when the page is saved. I just pushed an update yesterday for a bug someone reported with our config definition to CKE and it's enterMode option, but am thinking that is probably not related to the issue you are seeing here... Still it might be worth testing out hte new version 1.1.8 just in case.

Thanks Niklas. It sounds like I might need to contact PayPal about the issue then. Before I get in touch with them, I want to be able to duplicate the issue, so just had a two more small questions. We're you already logged into PayPal before going to the ProcessWire store? When it sent you to PayPal did you see the error immediately, or only after completing PayPal login or doing some other action?

Thanks for reporting this Niklas, I will look into it right away. A question about what you saw. The way the PayPal payment works is that it sends you over to PayPal's site, you pay there, then it redirects you back to the store (it uses PayPal IPN). Did you see the PayPal error at PayPal's site or at processwire.com?

We are now hosting our own store here at processwire.com (previously it was hosted through the DesignIntelligence bookstore). You'll see it as the STORE button on the upper left corner (next to FORUMS and MEMBERS). By hosting it here, we are able to provide better service to you. If you purchase a product through the store, your access in the forums is upgraded automatically at purchase time. Previously people had to request access or I had to track people down and tell them to create a forum account, etc. So the new system is much more automated. Now you can pay by credit card or by PayPal. Previously we could only accept credit card. Now you can purchase upgrades from one version to another. For instance, if you purchased ProCache Single and wanted to later upgrade to ProCache Developer, it lets you do so by paying only the difference in cost. This only works if you have done all the purchases through the new store. (If you did it through the old store and want to upgrade, then just PM me and I'll setup a special coupon code for you that subtracts the cost you already paid). The new store brings more revenue back to development of the ProcessWire project since our merchant fees are now a lot lower (2.5% rather than 10%). We will be adding more products to the store in the coming months, including more modules and enhanced ProcessWire support options for those that want it themselves or for their clients. A change to the FormBuilder and ProCache policies. Previously the developer or agency versions specified that you could install as many copies as you wanted, but only for 1-year (at which time you would renew if you wanted to install more). That time limit has been removed. When you purchase the developer or agency version of either product, you have no time limits. Incidentally, I've never enforced any time limits on either product, but just wanted to state it officially since I've recently been asked about it. The product pages also state this now. The only 1-year limitation that remains in effect is for support and upgrades. The new store lets you renew that automatically or manually, if you want to. The yearly support renewal cost is roughly 1/4 the product cost. For example, $10 for Form Builder Single. Coupon code (today through Saturday) To celebrate the opening of the new store and to make sure we put it through it's paces (not to mention, test the coupon code function) I've setup a coupon code that lasts from today to Saturday (April 1). The code will give you 10% off any Form Builder or ProCache version. The code is NEWSTORE. Please let us know if you see anything that we can improve in the purchase or checkout process. For those interested, the new store runs on IP.Nexus, which is a commercial add-on component to IP.Board (the forum software we use). The merchant gateway is provided by Stripe. A huge thanks to Pete (the forum administrator here) for recommending all this and helping to get everything setup.

Awesome site Soma! We need this one in the sites directory.

Looks like more replies came in while I was writing the above message. You mentioned you are on a shared server–who is it shared with? You may want to double check that your directories have safe permissions for a shared environment (if will vary per web host, and the web host can advise on what is best). Though since your tables needed repair, I would suspect something broke on the server (HD crash or corruption) rather than someone messing with the site. Have any new modules or code been recently added to the site?

What version of PW? I can't say as though I've ever seen tables get corrupted like that. But since you've got corrupted tables, you might also have a corrupted file system. I think Adrian's suggestion to replace your /wire/ directory is probably a good one. Have any new modules been recently installed? In your /site/config.php enable debug mode (change the line that says $config->debug=false; to $config->debug=true). You should now get a more detailed error message. Paste in the entire error message here if possible. You mentioned that you cleared out your "assets" folder. I'm hoping that you cleared out your "cache" folder in assets, and not the entire assets folder? Still it shouldn't be necessary to clear out the cache folder. Most likely something is still corrupted in the database or on the file system. You may want to export your entire database and re-import to a new database, then update it to point to that new database in your /site/config.php file (at the bottom). But while you are in PhpMyAdmin can you look at the list of tables and confirm that you have a "field_roles", and a "roles" table, both populated (not empty)? The error message you are getting makes me wonder if something is missing there.

I'm running out of time but quickly wanted to mention: $config->pagefileSecure = true; in your /site/config.php file (see the comments in the file and search google for more info). You might also want to look at the wireSendFile() function in /wire/core/Functions.php, if you'd like to protect the file in another manner.

If you've got a page that is being saved 5000 times a day, then presumably that's because it is displaying some dynamic data. That page would be inappropriate for ProCache, since it caches the entire page output. Though if the page is being displayed more than 10k times a day, then it might still be worthwhile to use ProCache. But keep in mind that there is a small amount of overhead associated each time ProCache saves a cache of your page. So you have to factor that in to the equation. With a page focused on displaying dynamic data, you might be better off doing selective caching with MarkupCache, or just not using the cache. Another technique I'll often use is to handle the dynamic data with javascript, perhaps sending an ajax request back to the server and displaying the result after the cached page has already rendered. But if you are literally saving the page 5k times per day, that's just a lot of cache saving and clearing either way. Isn't there some way you could queue those changes to be committed once per hour or per day or something, so that you can still benefit from a cache?

It can. Our sites directory is a good example of this, as it does pretty much everything you describe with FormBuilder. However, we review the submissions before approving them to be published on the site, and I always recommend this even if FormBuilder will let you publish directly. For instance, I've had a few submissions that were spam (though not obvious at first). Anything that gives users access to publish something on your site needs some eyes on it, unless you are dealing with a limited group of trusted users. But FormBuilder will let you do either.

Is $page->image a single image (max files = 1?). If so, access $page->image is an object of type Pageimage, which has no remove() or delete() or deleteAll() methods. Those are instead methods of the WireArray that contains the file(s)/image(s). You could access that a couple of different ways. One way would be to get the "unformatted" value, which for files, always returns the containing WireArray: $page->getUnformatted('image')->delete($page->image); Another way would be to access the 'pagefiles' property of the image, which also refers to the containing WireArray. $page->image->pagefiles->delete($page->image); I mention the above examples for explanation, but PLEASE IGNORE THE ABOVE. Any time you are performing manipulations to a page, you should have the page's output formatting turned OFF. So there really isn't any situation in which you would use the above API examples... because it would mean you are modifying a page that is in an output-ready state, rather than a change-ready state. That's why ProcessWire throws an exception if you try to save a page with output formatting state active. The second point I want to make is that simply calling a delete() is queuing a deletion, not executing it. You still need to $page->save() or $page->save('image') before the deletion is committed. Given all this, I think this is what you want: $page->of(false); // turn off output formatting $page->image->delete($page->image); // you can use this line... $page->image->deleteAll(); // ...or this line (choose one) $page->save('image'); // or use $page->save(); if also saving other changes

$config->paths->[property] refers to the server disk paths, and $config->urls->[property] refers to the corresponding URL. A Page object is something represented in a database, not a disk path on the server. So you can't draw a literal relationship between server paths and a page, since there is no physical file or directory for a page. Where you can draw the relationship is that the term 'path' or 'paths' always refers to the internal, server-side representation. Whereas the term 'url' or 'urls' always refers to to the external, client-side representation (something you would deliver to the browser).

Your showIf statements look alright to me, though I don't think that matters to what you are trying to achieve here. Assuming I understand correctly, $page->column is a PageArray of pages under /columns/ and you want to access the $columnOption property of those pages, which are themselves page references. (Either: Batch and Font Awesome). Your code for home.php seems correct, except that you aren't accessing the $columnOption property at all in your code. You'd mentioned "checking if a selected option is active or not". Is something like this what you are trying to achieve? foreach($page->column as $c) { if($c->columnOption->name == 'batch') { // output Batch icon echo "<i class='icon $c->batchClass' data-icon='$c->batchDataIcon'></i>"; } else if($c->columnOption->name == 'fa') { // output Font Awesome icon echo "<i class='fa $c->faClass'></i>"; } // output everything else echo "<h3>$c->title</h3><p>$c->body</p>"; }

The change to PDO was motivated more by the support of named parameters. Though bringing more abstraction to the DB layer also seemed like a good move for the long term, even without current plans to support other DBs. While PDO does abstract some of the considerations with supporting other databases, ProcessWire's queries are designed for MySQL, and are optimized for MySQL behavior. There's a lot of influence from the book: High Performance MySQL. Supporting another DB platform like PostgreSQL would probably not be such a straightforward thing. Though the truth is I don't know for sure, as I've not worked enough with PostgreSQL to know how similar or different the queries we use would be. But if you are looking at implementing some new fieldtypes, it would be best to look for how you might implement them with MySQL, since support for other DBs like PostgreSQL is not currently in the short term plan.

I think that usernames as MD5 hashes are going to be difficult to look at on the admin side, and kind of defeats the purpose of the name field being a readable, unqiue identifier. I would create a separate field to handle your md5 hash and add that to your user template. Lets say you created a text field called user_hash and added it to your user template. You could have it automatically updated every time a user is added or saved just by putting some hook code in your /site/templates/admin.php file $pages->addHook('saveReady', function($event) { $page = $event->arguments(0); if($page->template == 'user') { $page->user_hash = md5($page->name . time()); } });

ProcessWire is a tool for building things, so a Wiki wouldn't build itself. But when you've got a need for such things, it's always good to evaluate the software that is already out there to perform the task. For instance, I quite like the IP.Board forums, so see no reason to go build our forum in ProcessWire. Likewise, Wikis are an entire category of CMSs, with MediaWiki being the most widely known/used. After evaluating the options, if you decide not to use a turn-key package and that you'd still like to build it in ProcessWire, you'll find it'll be a whole lot easier than trying to build a Wiki elsewhere (I've always thought a Wiki would be quite fun to build in PW).

Thomas, there isn't any reason why it should take that long. Number of children/siblings makes no difference to how long it takes to add a page. As a result, I would look at what else is happening on your front end or in any modules that may be taking part here. Because the time seems to increase with quantity of pages, most likely you've got something loading all those sibling pages and pulling something from them. In particular, look for any $parent->children() or $page->siblings() calls that lack "limit=n" selectors in them. Feel free to post the code you are using and we can take a look at it.

You've got a hard-coded page assets URL in your javascript there, and the 1023 in it is referring to the page ID. Somehow you'd need to replace that with the ID of the page you are referring to, or better yet, call the $page->filesManager->url() to get the entire URL to it, rather than trying to construct your own. Getting either of those things will be fairly simple if your javascript here lives in one of your template files, as you would just refer to $page->id, or $page->filesManager->url() directly, and insert that value into the javascript. If this JS instead lives in an external JS file then you'll need to communicate that to the javascript somehow. One good way to do it is to use data attributes in your markup generated by your template file. Example: <div id='map' data-page='<?=$page->id?>' data-files='<?=$page->filesManager->url?>'> </div> Then from Javascript (jQuery), you can pull those values easily: var pageID = $('#map').attr('data-page'); var filesURL = $('#map').attr('data-files');

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

Remi, I'm not sure I fully understand the question, but it looks like you are getting a different result from swapping the order of your sanitizer calls? It should make no difference, but if it does then my best guess would be that something in the $translation object is getting changed as a result of accessing the 'clean' or 'translation' property.

I'm currently working on a couple modules that require newer versions of ProcessWire and newer versions of specific modules (as dependencies). Currently, there is no way to specify versions with module dependencies other than having your install() method throw an exception. As a result, module dependencies have been updated (on dev branch, 2.4.1) to include support for module versions, as well as PHP and ProcessWire versions. The best way to describe it is to show an example of how you'd use it. I'll take an example from the first post here and update it (note the 'requires' line at the bottom): public static function getModuleInfo() { return array( 'title' => 'Log Master (Process)', 'version' => 100, 'author' => 'Lumberjack Bob', 'summary' => 'Displays the logged actions in the admin', 'requires' => 'ProcessHello>=101, ProcessWire>=2.4.0, PHP>=5.4.0', ); ); The 'requires' line above specifies that this module has the following requirements: ProcessHello module version 1.0.1 or newer ProcessWire version 2.4.0 or newer PHP version 5.4.0 or newer If no particular version of a module is required then you'd simply omit the operator and version, as you've done with dependencies in the past. Another thing to note above is that the 'requires' line accepts a CSV string. Before, you had to use an array if you wanted to specify multiple dependencies. You can still use an array if you want to, but it's not required. The above 'requires' line as an array would look like this: 'requires' => array('ProcessHello>=1.0.1', 'ProcessWire>=2.4.0', 'PHP>=5.4.0') For ProcessWire or PHP versions, you need to specify a 2-3 part version string like "2.4.0". But for modules, you can specify either an integer or a 3 part version string. It's more consistent, and thus a little bit preferable to specify an integer (like in my first example) since that is already how versions are specified in the getModuleInfo 'version' property (i.e. 101 rather than 1.0.1). However, it doesn't really matter.

Thanks for helping me debug this. I'm not the developer of the stylesheets and so I'm still learning how this particular part is supposed to work. But the #top-buttons css in global.css is not something that I added there. It's always been there as far as I know. It's there because the mobile-first technique being used in the stylesheets dictates that the buttons don't show on mobile. But if you look in the layout.css file, which comes later in the CSS order, it has code to reveal them for the desktop views. It had a display: block for #top-buttons, but also needed a display: block; for #top-buttons .wire-button. I added it in there and that seems to have fixed it. But it's still a mystery to me why, as I don't think there had been any changes to these stylesheets for anything to do with the #top-buttons. But clearly there must have been. I think I can only blame it on not drinking my coffee fast enough one morning this week.

I definitely don't see them–tried in 3 browsers, they are gone in each. I'm only seeing the aroused chevrons in Chrome though.

Regarding the logo, we have Soma to thank for that (though others have also contributed). It was motivated by the need to stand out on Bitnami, though we've generally needed a mark for a long time. Soma worked tirelessly on dozens (maybe hundreds?) of variations of different logos, and came up with consistently fantastic work. Like ProcessWire, it's simple, but spend some time with it and you'll see it does more than you thought at first. You'll find it to be constructed of a wire, and the letter P (and a wire) being formed both in positive and negative space. Hope that you guys like it. Thanks again to Soma for the great work. I didn't remove the buttons, as far as I know. Though I did add the logo on the site a couple of days ago–maybe I screwed something up in the process? I don't know what. Also not sure what's up with the chevrons but I've been enjoying that too... though they aren't so much fun anymore. I'm going to dive in and see what's up. But I didn't do the front-end development for this site, so it's still somewhat unfamiliar to me. If anyone has a better clue of what's wrong with it, please let me know.