ryan

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 }

Thanks Pete, I will check this out. Right now I'm just trying to keep it consistent with Nikola's Futura theme, so it's using the exact same assets (Cufon, in this case). I don't even know what exactly Cufon is to be honest, I just copied it from his admin theme. However, each theme can have it's own assets, so there is no connection or dependency of Cufon to the blog profile. We won't standardize on any particular font system for the blog profile just because it's theme specific rather than profile specific. But I will definitely look into bringing in FontSquirrel into the next theme I make for it. One negative that I did notice about Cufon is that the fonts look pretty soft on the retina display, relative to all the other text. Not sure if this is a problem with other font systems or not, but just observed this about Cufon. Hold off on digging through it, because I have to post the new version. The one currently posted is very old at this point.

I agree with what the other guys said, but also wanted to add a note about the statement above. Since the rider belongs to one current team, you could make their parent page their current team, and have a multi-page reference reflecting their past teams. However, if these things will ultimately be public/indexable web URLs, then it's better to keep them in permanent spots in the structure and use page references for everything. That way the same URL can always access the same rider, regardless of time. Does something like a nationality ever change? If not, that may be a suitable parent for riders. I like having some structure where possible, rather than using page references for everything, but if everything can change then only use structure if changing URLs are acceptable (usually they wouldn't be). So far I'm thinking that you won't need/want to use repeaters for any of these needs. This sounds like a fun project. Especially with the Tour on now.

Actually I was using it for the Blog profile. I was using it so that you could select from what "widget" modules you wanted to display in the sidebar and sort them. The widgets were markup rendering modules. However, I went back to making the widgets as pages (selected as page references), as I thought it was ultimately more flexible. So in the end, I'm not using this module for anything. But think there will be other situations where it is useful.

Thanks for adding that Pete, it seems like a nice addition. Those are some smart line numbers too! Somehow they manage to avoid being copied/pasted. Most sites don't do this, I've been annoyed many times copying/pasting bits of code only to have to clean out all the line numbers that pasted. No such problem here--nice

I'm excited to hear about your new admin theme! I've taken quite a liking to Futura and have made a Futura front-end based on your theme for the new blog profile: http://processwire.com/blogtest/?theme=futura -- am I missing the mark with any of the details?

That's great Sinnut, thanks for posting that there! Seems like a good place to start. Now I need to make part 2 of that tutorial