ryan

I would like to provide this for sure. But so far I haven't seen that there is any demand for it. I'm sure the time will come. Well if they didn't think it was somehow incomplete, there wouldn't be any real incentive to have a paid package? But I know what you are saying, and that's why I'm not interested in having anything but the pure open source and free ProcessWire. On the other hand, I do like the idea of support packages and commercial modules-- they are special add-ons (separate from the core software) for people that want them. I don't think that having paid support options devalues anything else. The way I see it, it just is a form of insurance… a form of insurance that doesn't exist at present. None of us are obligated to support anything. We do it because we like to. But that's not a good enough answer for a company that depends on their web site. They want to know that if something happens that they can't solve, there is somebody obligated to help them in a timely manner. You can find that here in the forum, but it's based purely on the goodwill of the people here. I think it works now because our community is a nice size where it's easy to keep up with everything. When and if we get to the point of having 10x as many daily posts as we get now, it won't technically be possible for any individual to keep up with them all, at least not nearly as quickly. At that point, I think having more support options becomes a benefit to the perception of the project and helps attract big scale users that might otherwise look elsewhere. So it doesn't hurt to explore how best to handle the growth, even if we don't necessarily need it now. Here are some examples of commercial support for other platforms: WordPress: http://vip.wordpress.com/our-services/ Drupal: http://www.acquia.com/acquia-network-subscriptions MODX: http://modx.com/complete-maintenance-and-support/ Symphony: http://getsymphony.com/get-support/

I've found the column choice valuable for getting a different view on things. When you've got 4 columns, you can see a lot at once, but maybe you don't want to get too much into details or copy/paste because, depending on length, you may get wrapping like this: $page ->setOutputFormatting(true|false ) That's perfectly okay and expected, but for me the advantage of being able to reduce columns is that I can eliminate wrapping when I want/need to.

@jbroussia: Thanks, I have looked into this and it is a bug. I think it may be possible to make repeater fields cloneable, but they are kind of a unique situation and the factors involved in cloning them are more broad and complex than with others fields. So my solution for this now is going to be to have it detect when it's being cloned and throw an exception to prevent it from happening. Longer term, I should be able to figure out when I've gone 1-2 days to wrap my head around it. @Pete: He's talking about cloning fields rather than cloning pages. We did fix the issue with cloning pages that have repeaters. But cloning actual fields (Setup > Fields > some_repeater > Advanced > Copy/Clone) is a different thing. Hope to find a way to make these cloneable. But since this is the first time it's come up, I don't think there's a lot of demand for cloning repeater fields. Unlike cloning pages with repeaters, which is probably a more common occurrence.

Actually it's not going to be in 2.3, but it is a long-term work in progress. Versioning that is respectful of resources is rather complicated, especially when it gets into things like automatically created versions with file-based assets, repeaters, and the like. The system I'm working on keeps the version data outside of the pages system and page tree. But I'm a long way off from figuring out all the details.

I'm enjoying the animation here. Though if it were slow I probably wouldn't. But seems to be flying (in Chrome 20): very fast and smooth and just plain fun to use. I get a foundation building block feeling out of this (especially switching in/out of 4-col), and it relates well to ProcessWire as a builders tool. Sometimes it's hard to tell with animation whether it's best for long term. I remember my first exposure to the things going on in OS X and then iOS made me think I'd get annoyed with it. But it grew on me and made me enjoy using it more. Some of the animation in Windows was quite the opposite. Time will tell what the case is with the cheatsheet, and I may be wrong, but thinking it may grow on folks that aren't sure about it. Some of this is eye candy, but it's of the kind that attracts people and makes us look good, IMO. Either that, or I'm just really impressed because I've never seen anything like this before.

If you modify the Comments module, you don't want its updates. Updates would overwrite your changes. So when you do a PW update, you'd want to keep a backup copy of your custom comments module, replace your /wire/ directory, and then put your customized comments module back in place. You could also create a separate comments module (under a different name) and keep it in /site/modules/. That would ensure it never gets overwritten during updates. But the Comments module has several classes and files, so you'd have to do a lot of search/replace name changes. Personally I would find it simplest to just modify the built-in one and keep it backed up so it can be dropped back in after upgrades. This is what I've done in the one case where the client needed a custom comments module.

It depends on whether you are talking about 'autoload' modules or not. If the dependent module is 'autoload' and the dependency module isn't, then your dependent module can just load the dependency in it's init() or ready(), like this: public function init() { $dependency = $this->modules->get('YourDependencyModule'); } If the dependency module is 'autoload' and the dependent module isn't, then then dependent module can safely assume the dependency is already loaded. If both of them are 'autoload' then you don't necessarily know which will get loaded first. But by the time either module's ready() function is called, you know that both have been loaded: public function ready() { // safe to assume all autoload modules are loaded and have had their init() called } If the dependent actually extends the dependency (like one class extending another), or has code that needs stuff defined from the dependency before PHP will even parse it, then you need the dependency to have been included as a file first (like you'd expect anywhere else in PHP). As long as you reference the dependency class name in some form, it should trigger PW's class loader to find and include the file. Something like a "Dependent extends Dependency" class declaration should do that, as should a function call like: Dependency::getModuleInfo(). If you find that still doesn't do it, you can also try including it manually. But use the "once" version, i.e. include_once($file); or require_once($file). However, I don't think you'll have to go as far as doing this manual inclusion. Install Dependency Because load order dependencies don't usually require any intervention on your part, we usually think of module dependencies as being install related. ProcessWire has some things to help you in this area. You can specify this in your getModuleInfo() method: static public function getModuleInfo() { return array( 'title' => 'Module title', 'summary' => 'What the module does', 'version' => 100, 'autoload' => true, 'singular' => true, 'requires' => array('YourDependencyModule') // SEE THIS LINE } Here are all the details about module dependencies.

This is the MySQL ft_min_word_len setting (fulltext minimum word length). It's 4 by default, meaning it won't index words fewer than 4 characters. If we change it to 2 or 3, then it'll index words down to that size. Words like "the" or "and" are considered stop words (among a few hundred others), so they won't get indexed, regardless of what the ft_min_word_len setting is. I would guess that making IP.Board support fulltext indexing of words fewer than 4 characters would be exactly the same way that you'd do it in ProcessWire. Lets say you want it to index down to 2 characters: 1. Edit /etc/my.cnf and add this to the top: [mysqld] ft_min_word_len=3 2. Save and restart MySQL (either from command line or WHM). 3. Open the database in PhpMyAdmin, check the box for all tables (or at least those using fulltext indexes), and click "Repair" in the select box at the bottom. After that it should work. The only problem here is that ft_min_word_len is a server-wide setting. So if there are other databases on the server using fulltext indexes, they also need to have their indexes re-created (by running the repair, as described above). If the databases are left un-repaired, their indexes will get corrupted and eventually start throwing errors. That is fixed by doing the same repair operation, so might as well do it sooner than later. I will take care of changing this setting and repairing all the relevant databases when we launch the new PW site.

An easy way to do this is to go into your admin (either before or after migration), click "Modules" and locate the "Page Render" module (under the "Page" headline). Click it to view it's settings page. It'll tell you how many files are in the cache and give you a checkbox to clear it.

Also wanted to mention that in 2.2 a "push-to-top" and "push-to-bottom" option was added for images. Hover over any image in a list and you'll see them as up/down arrows. Click the up arrow and it pushes it to be the first image at the top. Click the down arrow and it pushes it to the bottom. This makes your client's sorting scenario a lot easier, especially when dealing with lots of images.

Thanks Arjen! This is the sort of stuff that PW was designed for, and I think is also the most fun stuff to develop with it. There is almost always a way around any pitfalls. Please keep us up to date with how your projects go and with any questions you run into along the way.

I think your files field may not be fully created yet. Go back to that field in Setup > Fields and hit save. Now try it again. If you still get the error then go back to that field again, click on it's "details" tab and note the file extensions. Make sure that the file you are uploading is in the list of allowed extensions. Add more extensions as needed and save the field.

You can just rename your /site/templates-admin/ to something else. If I want to disable a custom admin theme temporarily, I just rename it to /site/_templates-admin/ (prepend an underscore or some character to it).

If I understand correctly, perhaps you could store your links as pages. Your 'link' template would have a 'title' and URL field called 'href'. You'd store these pages under /links/ or wherever it makes sense in your site. The 'link' template file code would just be a redirect: <?php $session->redirect($page->href); When you link to these resources in TinyMCE (or elsewhere) you'd link to the /links/some-site-link/ page(s). That would abstract away the actual link to be something that you could change in 1 place and expect that any links to it will get redirected to the right place.

I appreciate the interest. There isn't currently a donation capability here right now, though I hope to figure it out this year. Since I incorporated my business a long time ago (2003), ProcessWire is technically built by RCD (Ryan Cramer Design, LLC), so not really sure how to handle donations given that it's a corporation. I think I just need to do more reading, but I find the material hard to understand, so it's slow reading. Probably what I will do is move ProcessWire to it's own legal entity (non-profit entity or foundation if possible). And that should make it straightforward to accept donations as well as make them tax-deductible for the people that donate. But until then, the best way you can donate to the project is staying involved and active, and spreading the word online when and where possible. I think that are a lot of people that may benefit from ProcessWire that don't yet know about it.

Try switching back to the default admin theme, just in case that's got something to do with it. Because the errors you mentioned sound unique and unusual, I would also suggest running a database repair. This is quick and easy to do from PhpMyAdmin--let me know if you need help.

Here's another option: $field = $fields->get('your_page_select_field'); $inputfield = $field->type->getInputfield($page); $options = $inputfield->getSelectablePages($page); The advantage is that it'll work with all selectable pages settings (i.e. template, selectors, code, parent). Whereas the previous examples assume the selection is built just around a parent (which is perfectly fine too if that suits your needs).

On the admin UI side, what are you using for selection of topics and subtopics? What I'm trying to determine is if topics and subtopics are separate fields, or if you've combined them into one and are using something like a PageListSelect? Your answer to this would help to determine if you are using the right fields on your selector. I think that Soma's example should work. Your example won't work because it's using $pages->get() rather than $pages->find(), so it would only return 1 page. Though it's still a valid API call so I wouldn't expect it to return an error: what is the error?

In your getModuleInfo() method, delete the "'permanent' => true" line, as that only makes it impossible to uninstall the module (which we only want for select core modules). In your init() method, you are adding a 'toJSON' method to the $pages API variable. But your pagesToJSON() method appears to be written like it's meant to interact with a PageArray. As a result, I think the problem is that you need to change your hook like in the init() method to be this: $this->addHook('PageArray::toJSON', $this, 'pagesToJSON'); I am guessing that the source if the error is that you are trying to call toJSON() on a PageArray when it's not hooked there. Hopefully the above change should fix it.

I think you'd need to be more specific in your question and give this context: What will you sell (products, services, e-books, etc)? Will your store need to handle taxes and/or shipping? What payment types do you want to support? What countries are you selling in? Are you subject to PCI compliance? Have you ever managed an e-commerce site before? There is a ProcessWire ecommerce module that @apeisa has built and is building, as discussed in this thread. While I am not an expert on that module, your answers to the above questions may help others to make suggestions as to whether that module would be good for your needs. If you find you can't answer all of the questions above, or don't yet have any e-commerce experience, then my suggestion would be this: Regardless of what CMS you are using, use an e-commerce service rather than trying to run your own. It's one of the most complex online applications, especially with PCI compliance, shipping, and taxes. Personally, I use http://shopify.com and am happy with it. Another user here mentioned they are happy with http://lemondstand.com . Many of these services (Shopify at least) include web hooks that allow you to trigger actions on your ProcessWire site (like creating subscriber access, for instance). This opens up a lot of power without requiring a lot of work or expertise about ecommerce on your part.

I would probably make current_team a single page reference, and past_teams a multi page reference. Meaning, two separate fields. Lets say that $team is a Page with the current team. A team could find it's current members like this: $riders = $pages->find("current_team=$team"); and past members like this: $riders = $pages->find("past_teams=$team"); I know I said before that I didn't think there was a place for repeaters here. But now I take that back. Here's an alternate approach that might be handy by using repeaters: You could setup a repeater called 'teams' and have it contain these fields: team (single page reference) year (integer or page reference) Then you could find all current members like this: $riders = $pages->find("teams.team=$team, teams.year=2012"); and past members like this: $riders = $pages->find("teams.team=$team, teams.year<2012"); The other option you mentioned: retired checkbox with first or last being current, also seems like a fine way to go. But that does make it harder to quickly differentiate between current and past teams, at least from the context of $pages->find(). So I think it may be better to use one of the options above. If you use the repeater approach mentioned above, you could add a checkbox to the repeater that indicates they are a participant. So if you wanted to find all partipants (the 6 rather than the 15) for $team in the year 2012: $participants = $pages->find('teams.team=$team, teams.year=2012, teams.participant=1"); Lets say you wanted to output a table like your example link: http://www.cqranking...r.asp?riderid=7 Here's roughly how you'd output that: $rider = $pages->get("name=lance-armstrong"); foreach($rider->teams->sort("-year") as $team) { echo "<p>"; echo "Year: {$team->year}<br />"; echo "Team: <a href='{$team->team->url}'>{$team->team->title}</a><br />"; echo "Participant: " . ($team->participant ? "Yes" : "No"); echo "</p>"; } Should give you a result like this:

Thanks Pete, good to know about the difference there. That definitely explains why Cufon goes soft on the retina screen (iPhone at least). I will make a point to avoid Cufon.

@pete: it stores the target as the page ID rather than a URL so always going to redirect to whatever is the Latest ver of the page. (ie no extra redirects) @diogo: it doesn't look for redirects unless a 404 has already been triggered. So if the requested path matches a page in the system, a 404 never gets triggered and this module would not come into play. @WillyC: please try that out and report back what you find?,

We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules'). The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples: Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/. You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/. Those are simple examples, but this module can handle more complex situations too: Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/ Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects. You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL. TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.

Great post! PW is a lot different than Drupal in this regard, but no less flexible. Between page references, structure, the API, and markup under your control, I think you can take PW further than you can Drupal. Another aspect of PW that I wanted to mention that is easy to miss: PW supports unlimited granular permissions. You can simply add new permissions in the admin (Admin > Access > Permissions). Then edit any roles you want to have those permissions and check the appropriate boxes. From that point, you can use those permissions in the API however you want. For instance, if you'd created a permission called "sugar-in-coffee" then you could check if the current user has that permission by using the API: if($user->hasPermission("sugar-in-coffee")) { // do something } Something else you may find handy is if you want to provide additional access without a user having to login. Lets say you are performing some check with the IP.Board API to determine if a user of a certain level is logged in there, and you want them to have upgraded permissions in PW at the same time. Create a role that has the permissions you want. Then you can assign that role to guest when you detect they should have additional access: if($user_is_logged_in_ipboard) { // or however you perform this check $user->addRole('member'); // where 'member' is the role you added // now user has more access } or if you want to login a specific user in PW, but don't need to authenticate (because they already authenticated in IP.Board): if($user_is_logged_in_ipboard) { $u = $users->get($ipboard_user_name); if($u->id) $users->setCurrentUser($u); // now a user is logged in for this request, without having to authenticate }