ryan

See the FormBuilder or ProCache Dev version, as the plan is to license this in exactly the same way. Since this comes with multiple modules, I don't see a reason to have a single site license because you might like to use one module on one site and another on another site. So I'd rather just license this one as a buy-once use anywhere type thing. These modules won't be part of the core. They are a separate product from ProcessWire in the same way that FormBuilder and ProCache are. However there is one exception: FieldtypePageTable (not FieldtypeTable) is one of the ProFields and this one is being included in the core thanks to a sponsorship by Avoine. I'll be covering more about this Fieldtype soon, but it's already available in the dev branch and a great addition that I think many people will prefer to repeaters. The idea and concept for this field was designed by Apeisa and I think folks will love it. That's good to hear that you think so highly of these modules! But since nobody outside myself has developed a site with these modules, they definitely aren't essential to building a site with PW. Though they are certainly useful and big time savers! The tools essential to building great sites with PW will always be core. Like with FormBuilder and ProCache, the intention with premium modules is to provide time and/or resource saving tools for those that make a living from this and want additional tools to support their work. In addition, purchase of premium modules is a way to support the ProcessWire project as a whole (since we don't take donations). Where multi-language is needed, ProFields are intended to be used with ProcessWire's language alternate field support. Most ProFields involve lots of inputs and it's not practical to multiply those per language the way that FieldtypeTextLanguage does. Though they can work quite nicely in the language alternate context. Beyond language alternate support, Textareas can be used in a multi-language context, but since you define what each component is, you'd be responsible for defining separate components for each of your languages. Meaning, it's not specifically a multi-language field, but you can choose to use it in a manner that supports your multi-language needs. If we find that there are practical ways to expand upon any of the ProFields for further multi-language support, and there's sufficient demand for it, then we'll certain do what we can there too.

Yes good point, the volume is a little low on this. I should have normalized it before publishing. I'll try to remember that on the next one.

ProcessWire ProFields is new product that will soon be available in the ProcessWire store. It consists of 4 really useful new modules: Textareas (Fieldtype + Inputfield) Multiplier (Fieldtype + Inputfield) Table (Fieldtype + Inputfield) AutoLinks (Textformatter) These modules are currently in beta testing, and I'll be posting screencasts to highlight some of the features of each over the next week or so. To start with, here is a screencast for Textareas: This video includes sound (narration) and I recommend viewing it at a larger size than above (preferably full screen), and bump it up to the 720p resolution so that you can see everything in better detail.

FormBuilder is for building one form at a time. While you could fake a multi-page UI with dependencies, or even connecting multiple forms, It sounds like your needs might be more consistent with a survey or application software. I'm not aware of any good non-hosted solutions in this area, but something like WuFoo or SurveyMonkey might be a good one to look at. Google also has a form tool that can populate into their own spreadsheets, and it supports multi-page (and at no cost). Though the forms themselves are pretty limited and not so customizable. Still, they are worth looking at. But I would check WuFoo first.

This is specific to any CMS or software you might run on a server (not just ProcessWire). When it comes to the security of the hosting, I prefer something dedicated (VPS or dedicated) so that you don't have multiple websites (managed by other users) sharing the same file system. When you are dealing with a shared file system, you've got more to consider when it comes to the permissions of files and such. You need to make sure that the permissions settings you've chosen for uploaded files and such is not going to give other accounts the ability to change them. You are also likely sharing MySQL instance with other users in a shared environment as well, so there's that matter of resources being shared. You can certainly secure the shared environment just as well as the dedicated one, but it'll take more work and monitoring. Shared hosting environments also represent a bigger prize to hackers, so that seems to be where they prefer to focus their efforts. I would go with a managed dedicated or managed VPS. For example, I think all the servers available from ServInt are managed (I know this one we're on right now is). One other recommendation would be to isolate your software. Don't run WordPress and ProcessWire from the same account if you don't have to. WordPress is always a target, and if you get broken into that way, then you could create problems for everything else running on the same account (this is not uncommon with WordPress at least).

While uploading should work form the user profile, the Ajax/HTML5 uploader isn't intended to work on the user profile page. Note that it lacks the "drop files in here" label. I'd consider the non ajax upload a little more secure for a user profile, which may be accessible to someone that doesn't have page-edit access. So ajax/HTML5 upload isn't enabled on the profile editor. On the more technical side, the ajax field capability is a function of ProcessPageEdit, and ProcessProfile isn't built around ProcessPageEdit (since it's intended to be more locked down), so it doesn't inherit that capability. In testing here, image uploading seems to work (without HTML5/ajax uploader of course). I'm testing on the latest dev branch. Are there any other conditions necessary to reproduce the issue?

ProCache version 2.0.0 (now in beta, available in the ProCache board) adds these new features: Multi-host support If you've got multiple hostnames pointing at your ProcessWire site, now you can cache them separately. SSL / HTTPS support ProCache will now optionally cache HTTPS requests separately from HTTP requests. Switch to PDO queries Previous versions of ProCache used MySQLi. This new version now uses PDO, consistent with ProcessWire 2.4.0. This improves performance when generating and maintaining caches. Requirements ProCache 2.0 requires ProcessWire 2.4.0 or newer. ProCache 1.x still supports previous versions of ProcessWire.

Thanks for posting the solution you came up with here. One thing I just wanted to mention is that you may be better off using some kind of language gateway or language switcher at the top of the page (something that can be understood by all your target languages) and ensuring that each language version of a page resolves to a different URL (ensuring no 1 URL is serving more than 1 language). My understanding is that Google advises against modifying the output of the request based on the accept_language header, and thus could be an seo concern.

Not sure I understand. Queries wrap for me at least? I don't think there is (unless getting into some internals of PDO). The prepare() method where queries are logged comes before variables are bound. Plus, variables are bound internally via PDO statement objects and not via ProcessWire.

I don't understand the question, and I'm guessing others didn't since this one hasn't had a reply yet. For instance, what do you mean by children pages inheriting $users... are you talking about template access control, or something you are doing at the API level? But one thing I did want to mention is that $users is a ProcessWire API variable, so that may be a point of confusion (and probably a field/variable name you want to avoid using if referring to something else).

wire('ModuleName') is not a syntax that ProcessWire uses. You can just retrieve API variables from wire(), like pages, page, user, session, etc. To retrieve a module, you would use $modules->get('ModuleName'); It's true that some autoload modules might set their own API variables that can be accessed with wire(), but most don't. One example of an autoload module that does that is LanguageSupport.module, which sets a 'languages' API variable that can be accessed via wire('languages').

I have a feeling you are hitting up against mod_security here, because there is no logical reason why some markup in a field should cause that error, unless something was modifying the submission. mod_security can be pesky in that it doesn't like certain combinations of markup in POST vars, especially <script> tags. One thing you could try is converting the script portion to a Hanna code, though mod_security might still give you trouble... so you could trick it by using a PHP Hanna code that does something like this: echo "<"; echo "script"; echo "async src='...' charset='utf-8'></"; echo "script"; echo ">";

You might need to grab a fresh copy, as it sounds like you might have a partially installed copy where some settings are already present. What does the URL in your address bar show when the error occurs? You mentioned "/install.php" but what about the hostname and path?

There are plenty of ways you could implement subcategories. I think the most logical way might just be to make them subpages of the existing category pages. As for how to make them selectable, this method works nicely since it ties the available subcategories to the selected categories.

A few new/minor additions on the dev branch: You can now paginate with "limit=1" selectors. Previously ProcessWire didn't build the pagination information when a limit of 1 was specified. Now it does. ProcessWire now preloads pages that it knows it's going to need on every request. This speeds up everything slightly, as what was previously done in 6-7 queries is now done in one shot. Should you want to, you can also specify additional preloaded pages, though I don't think many (any?) would need to. Several optimizations to the PageFinder engine which improves the speed of certain types of queries. One of them is a $pages->count("selector") query, which is now even faster than before. Selector Grouping Added support for selector grouping to change the behavior of how they match. This is best explained by example. Lets say we're building a big news site, and we have a template called news-item that represents each news article. Each news-item page has a field called cats that is a multi-page reference to one or more category pages. This is a pretty common scenario in ProcessWire. The site has a lot of categories, so want to designate some categories as featured so that we can display featured categories on the homepage and elsewhere, with accompanying news items. Rather than just adding a featured checkbox, we add two fields to represent the date range that we want them featured: featured_from and featured_to. On our homepage, we want to display articles from all the current featured categories, so we build a selector like this: $items = $pages->find("cats.featured_from<today, cats.featured_to>=today, sort=-date"); ...but we end up with more news-items than we expect, including some that have categories that aren't actually featured right now. Why? Because each news-item can have multiple categories, and that selector above is saying this: The keywords there are "at least one", as "categories.featured_from" and "categories.featured_to" may not be referring to the same category. The only way to solve it was this: $categories = $pages->find("template=category, featured_from<today, featured_to>=today"); $items = $pages->find("categories=$categories, sort=-date"); That's easy enough... but now you can also do it like this, by prepending an @ to identify a group: $items = $pages->find("@cats.featured_from<today, @cats.featured_to>=today, sort=-date"); The "@" symbol at the beginning of "cats" is telling ProcessWire those are grouped together and "these must match the same exact page". This was added because there are situations where you need to perform your query with 1 selector rather than breaking it up. An example would be when used with the new InputfieldSelector module and Lister, among others. We will likely be adding more ways to perform complex matching scenarios with a single selector as well. Currently this "@" grouping applies only to multi-page reference fields, as I'm not sure yet where else it might be useful. It is only supported by selectors that hit the database at present (though will be completing it for in memory selectors as well). Not planning to extend it into that area at this time, but good ideas to think about for the future or for modules. It should already be fixed. If we're talking about the same thing, someone recently posted this to the GitHub issues list and I added their fix on dev. Adrian already knows this because we've been chatting in the GitHub issues queue, but for anyone else reading this, it has also been fixed.

After writing it all up for that forum post, I wasn't satisfied with having to make edits to two templates in order to enable the feature. So I've gone back and re-done this feature. The instructions and screenshot have been updated (see my post above). Now you only have to edit one template, and all settings related to it are in the 'Family' tab. I've also added a "title" option, where it will auto-generate your page name from the title, just like you are probably used to. Because the title isn't yet known when the page is created, it assigns a temporary name to the page, then overwrites it once you give your page a title.

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.