ryan

I updated the wording on the page to just this: "The license to install ProFields and receive support goes to the purchaser."

Sorry, I will try to word that better. What it means is that that the license to create new installations goes to the purchaser. If it's purchased on a client's credit card, then they are the purchaser. If you pay for it, then you are the purchaser. The purchaser can put it on any sites that they design/develop (whether for themselves or their clients). If you want to mark it up and charge the client for it, that's fine. It's just that when you buy a product in the store, you are buying support of the product, so we have to know who is the person that gets support. That's all it is.

This is not possible, as fields in the Table represent literal fields in a MySQL database table, not ProcessWire fieldtypes. For instance, when you define a radio buttons or select input in your table, you are literally defining a MySQL ENUM field. And when you define a checkboxes input, you are literally defining a MySQL SET field. In this sense, the Table field is incredibly efficient and fast, as there's really no middle layer between your content and the database table. However, if you need multi-language text fields, you'd want the flexibility of either Repeaters, or the new PageTable field (now available for free on the dev branch). All the ProFields are available as of this morning in the ProcessWire store. I agree regarding Joss's voiceover. He heard my other pirate voiceovers and basically said: "step aside son, let me show you how this is done." I wrote a rough script and sent it to him. 30 minutes later, he replied with a voiceover that had everything in the script but majorly improved and with SO much more good stuff. All the funny lines are all Joss. My favorite is the "chuck 'em overboard to let the porpoises nibble on 'em."

Good question Alan. Here's a screenshot of the module config screen that I think answers your question. See the two settings at the bottom where you can define the max times to link and the distance required between links. AutoLinks is of course also smart enough not to attempt linking things that have already been linked.

Introducing ProcessWire ProFields: Table – it lets you literally define your own Fieldtype! This is one of the most exciting ProFields and it's something very different than any other Fieldtypes. I think it is best described by this screencast (be sure your sound is on): Special thanks to Joss for his great voiceover on this screencast. Please view the video at 720p and full screen if possible. Read more about the Table Field Table is part of the ProcessWire ProFields package now available for purchase in the ProcessWire store.

Introducing the AutoLinks Text Formatter, part of the ProcessWire ProFields package of modules. What it Does This Textformatter module automatically links your specified phrases/words to your specified URLs. This is an excellent SEO and accessibility tool for creating automatic contextual links with little effort. If there are pages that you commonly link to in your site from your textarea/rich text fields, then this Textformatter can save you a lot of effort, automatically linking to those URLs. Furthermore, contextual links of this sort are also considered especially valuable from an SEO context. Because this module is a Textformatter module, the work it does happens at runtime. That means that this module can easily be applied to existing sites, no matter how large. Usage Example We'll use processwire.com as an example. Throughout processwire.com, we routinely use the terms "API", "selector", "template", "template file", "$page", "$pages" and more. In the past, I've spent a lot of time in TinyMCE manually linking these terms to the appropriate pages, as it is a helpful cross-reference for users. For example, when the term "API" appears, I want to automatically link to the API Cheatsheet page at http://cheatsheet.processwire.com. With the AutoLinks Textformatter module, I can now automatically link to all my important terms from all existing and future body copy. If one of those links happens to change in the future, no problem, as I only have to update it in one place (if at all). The benefits here are a real win win for the users of processwire.com, myself (in time savings) and our performance with search engines that analyze these contextual links. We hope that you find AutoLinks to be a huge benefit to your site(s) and time saver for you and/or your site editors. AutoLinks is available for purchase as part of the ProFields package in the ProcessWire Store.

You can multiply any type of field that holds a single value/property. This includes Text, Textarea, Integer, Float, Email, Datetime, Selector and URL. It can also multiply 3rd-party Fieldtypes as well (so long as they are single-property).

Similar only in the multi-value aspect. Repeaters are creating a new page for each item, and that page can have any fields. That's incredibly powerful, but also consumes a lot of resources. That's why we don't recommend repeaters in large quantities or other large scale usages. Multipliers on the other hand multiply an existing Fieldtype like Text, Textarea, Integer, Email, etc. (including those that don't yet exist), without any overhead or additional resources. They are incredibly scalable. Like all the ProFields, Multipliers are a tool that enhances things you can already do [with repeaters] by doing them more efficiently and in a more focused way. They are especially desirable those using PW for large scale projects. They may also be preferable from the admin UI aspect in that they don't have to be as flexible as repeaters, so they can stay more focused on the UI side as well. Language text fields (FieldtypeTextLanguage and FieldtypeTextareaLanguage) are multi-property fields. Multiplier can only multiply single-property fields at present (though most Fieldtypes are single-property Fieldtypes). On the core side, Multiplier can multiply: Text, Textarea, Integer, Float, Email, Datetime, Selector and URL. It can also multiply 3rd-party Fieldtypes as well (so long as they are single-property). However, it is technically possible to multiply multi-property Fieldtypes as well, so I am planning to add support for multi-property Fieldtypes in one of the next versions of Multiplier. This would enable you to multiply Fieldtypes like TextLanguage, TextareaLanguage, and MapMarker (and other 3rd party multi-property Fieldtypes). Since there are a whole lot more single-property Fieldtypes, Multiplier is focused on those for this first version.

Previously I posted about Textareas. The next field coming in ProFields is called Multiplier. This field lets you take almost any existing single-value Fieldtype, and use it as a multi-value Fieldtype. Single value Fieldtypes are those that store one piece of information at a time, for example: Text, Textarea, Integer, Float, Email, URL, etc. Any of these, and more can be multiplied with Multiplier. Here's a short video introduction to Multiplier. Like with the previous screencast, I recommend upping the quality to 720p and viewing full screen. This one also includes narration, though we're in allergy season here so my voice is a little rough. The next fields I have to tell you about in a few days are: Table, PageTable and AutoLinks.

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.