ryan

What version of PW? What happens if you change 'booked=0' to 'booked=' or 'booked=""' ?

It seems like we should be able to change that behavior but I can't initially figure out why it's not accepting your argument to the render() method. Just to be clear, $slider is an individual Page (rather RepeaterPage) and not a PageArray? And the render() method is intended to be Page::render? One possible factor may be that repeater pages have their own class: RepeaterPage rather than Page, and this might be interfering somewhere along the line, but not yet deep enough in the code to see where.

I also would like to make it more configurable, and definitely plan to. But in the short term, I think the best bet is just have it not show if there aren't any add-ready templates to populate it with. I will do this before 2.4 is final, but just wanted to keep it there with a little instruction notice to introduce it, as I thought people might not realize the option was there otherwise. Thanks for the screenshot comparison. It looks like the "e" also has the same issue with the bold Open Sans, though to a lesser extent. I notice the 12px size seems to look fine with both by comparison. Is the problem just the 14px font size with these fonts in Windows? Would using a different size (bigger or smaller) as a default be better in the Windows environment?

Without that setting, pages like Home and Trash would retain those labels unless the the LanguageSupportFields module is installed. Since this is an optional module, I figured the system pages should still be translatable via a language pack.

What's on line 71 of that file? Was the PHP version downgraded in the transition? Make sure you are running PHP 5.3.8 or newer on the new server. The table for the field may exist, but does it have an entry in the "fields" table? That error message would suggest it doesn't. I am guessing the database didn't successfully import to its new location. I would try to re-import the whole thing.

I'll try to get this one in later today. This is actually the intended behavior because names specified in each language may not be unique. For example the spelling of Chocolate is the same between English and Spanish. But there are many examples, and it's very common to have the same page names across languages. As a result, "name" in a selector refers to the actual page's name, and not it's name in another language. While names aren't unique for the same page across languages, paths are unique (otherwise PW has no way to determine the language) so that's why your retrieval of the path worked but the name didn't. This is one that we can feasibly get working without too much trouble, if there's a need for it. One way you could do it is to change your "name" selector to a path selector: $p = $pages->find($page->parent->path . "namefor_german");

I don't know enough about the Facebook API to know what's wrong here. But I would guess the Facebook authentication is failing and that you need to retrieve an error code or error message from it in order to know why. Does it have some kind of getError() method that you can call? Also your try/catch block is pointless here, as there's nothing with your try/catch block that can throw an exception. But I'm guessing that's just there as a placeholder that you'll be populating later?

ProcessWire's permissions system is designed to deal with groups of pages (by template). When you get into wanting to assign permission for a specific individual page, the best way is to use your own code to identify the page. An example would be a hook in /site/templates/admin.php wire()->addHook('Page::editable', function($event) { if($event->return) return; $page = $event->object; $user = wire('user'); // if page ID is 123 and user is "joe" allow edit access if($page->id == 123 && $user->name == 'joe') $event->return = true; });

Not currently with this module. Though you could write a quick file to do it for you. Place the following in your web root where ProcessWire's index.php file is, perhaps in a file called fix-names.php. Then load it in your browser. <?php include("./index.php"); // bootstrap PW $items = wire("pages")->find("template=your-template"); foreach($items as $item) { $name = preg_replace('/-s(-|$)/', '', $item->name); if($name != $item->name) { echo "<p>Changing $item->name to $name</p>"; $item->name = $name; // $item->save(); } } Uncomment that $item->save(); after you run it the first time to make sure it's doing what you want. I wrote the above here in the forum and haven't tested, so it may need tweaks.

Alessio, i think your solution might be the one we've been looking for. While sleepValue() would ideally return a float, that's just not possible here unless MySQL recognizes the same float format as the PHP locale (which apparently it does not). So converting to a string actually seems like quite a good idea. I am going to make this change on the dev branch and test it some here, but so far I think this seems like the best solution.

It looks to me like the database did not successfully transition to the new server. You may want to re-import your database and double check that all the tables are present that were present in the previous environment. Also make sure you've got the right credentials for logging into the database configured at the bottom of your /site/config.php file.

For Soma's code to reset the password above, you might also need to add a $u->of(false); to turn off output formatting, before doing the save. But the "request aborted" message you are getting makes me think there's a file system write problem and sessions aren't saving. Your actual /site/assets/ might be writable, but is everything in it writable? I'm guessing not. You probably need to do a recursive reset of the permissions in there so that the server can write to it. On a unix system where you wanted to make it globally readable/writable you'd do it like this: chmod -R og+rw /site/assets/ That may not be the appropriate setting for your server, so it's one to check with your host about if you want to ensure the best security.

It's hard to tell for sure without knowing the full scope of your user, role and permission settings as well as other things about the context. Keep in mind that a user can have multiple roles, and they will gain the combined set of permissions from those roles. Also keep in mind that these roles are activated for pages on a per-template basis with each templates' settings. If the combined permissions for a user don't allow them page-move or page-sort permission, then they shouldn't see a "move" link in the page list, nor should the see a "change parent" section in the page editor. Of course, this can all be overridden by modules and hooks. But I don't see anything in the code you've posted that would indicate it's overriding either of those permissions.

Not sure I understand the question? But I'm guessing you might be talking about caching. You could certainly cache (and probably should), using the caching features at the template level.

There is actually a redirect between the form save and the next form edit. Meaning, you don't get to see anything when the form is actually saving. For debugging purposes in this case, you can use $this->message("your debug message"); and it will be queued for the next page view. If it helps with debugging, you can also temporarily comment out the $session->redirect() in ProcessPageEdit.module.

If new posts are working and not old posts, then it definitely sounds like a directory permissions issue. Most likely the directories represented by the old posts are under a different account ownership than the new ones.

To prevent it from truncating in the middle of a word, you'd have to go back to the original bit of code. It first truncates to 450 characters. You can increase or decrease that number as needed, but it should represent the absolute maximum number of characters allowed in your summary. You may potentially need to remove the strip_tags(), as I'm not positive what that does with Japanese. $summary = strip_tags(mb_substr($page->body, 0, 450)); Next, you want to find the position of the last space within the 450 character block of text you just obtained, and then truncate to that. That's what the strrpos() or mb_strrpos() function does. I don't know Japanese, but if the word separation character is something other than a space, then you'd want to use that rather than the ' ' that appears below. $summary = mb_substr($summary, 0, mb_strrpos($summary, ' ')); Now that you've got $summary, try outputting it to see if it has what you want? I'm guessing it does, but don't know for sure. If it does, go ahead and populate it back to $page->summary and output it again: $page->summary = $summary; echo $page->summary; Has anything changed, or is it working the way you intend?

trackChange() is a method on every Wire derived object, which includes most of ProcessWire's objects. The question would be what you are calling trackChange() on and whether the change tracking state is on or off? Also, there are related methods, also accessible everywhere that trackChange() is: // turns change tracking ON or OFF $obj->setTrackChanges(true|false); // returns TRUE if change tracking is ON or FALSE if off $bool = $obj->trackChanges(); // returns an array of changes that have occurred $array = $obj->getChanges(); // tracks the change, only if change tracking in ON $obj->trackChange('field_name'); // clears the list of tracked changes $obj->resetTrackChanges(); // hook that is called anytime a change occurs: only useful if you want something to be notified of a change $obj->changed(); My best guess is that you may need to call $page->trackChange('field_name'); rather than the form itself. That's because the form is managing most of that on it's own, and may be clearing/resetting the trackChange call you did. Also, a page's changes are cleared after a successful save(), if that matters.

I actually have been working on a module called Lister that does much of this. Though it's not yet quite as flexible as I'd like it to be for release, so I'm mostly using it in my own projects until I can get the time to take it all the way.

There really isn't much point in a cropping=false value to this particular call, because that would force a stretched image... something that there is almost never a practical use for. You'd be better off just specifying only a width or height, to ensure you don't get a stretched image. But you are correct in that for the most part, ProcessWire only maintains one thumbnail per dimension. There is one exception: if you specify details about where it should crop, it should keep separate copies, i.e. $img1 = $image->size(200, 100, array("cropping" => "center")); $img2 = $image->size(200, 100, array("cropping" => "northwest"));

Xeto, welcome to the forums. You have a few options: 1. Leave the data in your tables and just query it from ProcessWire using $this->database (PDO) or $this->db (mysqli). 2. Export your tables to a spreadsheet (CSV) and import using the ImportPagesCSV module. 3. Query or export your data out of your existing tables and create new pages from the API. This is the route I usually take. See the cheatsheet. Also see the Data Conversion section (at the top) of the CMSCritic case study, which describes how to query data out of an existing table and create new pages from it.

This module does two things: 1. Gives you the ability to perform text matching on page paths/urls with selectors, i.e. $pages->find("path%=blahblahblah"); 2. Adds an index of page paths in a separate table, potentially making retrieval of a page by path faster. Meaning, it can increase the performance of $pages->get("/path/to/page/"); and similar types of retrievals. I honestly haven't used this module all that much. Its performance benefit is theoretical and I'm not sure it's actually measurable. As a result, I'm not sure I'd necessarily install it unless you want to perform text matching on page paths. This one will probably be removed from the core in PW 3.0 and kept as a 3rd party module.

Brent, if I understand correctly I think I agree there. Though if you are wanting to query the code like "35" then your selector probably needs to be something like "template=program, code.title^=35". This may be a dumb question, but if the content editors already know the geographical codes, why use page references? Could you just store the codes themselves? Assuming both the matching string "35" and the resulting page references need to be stored, then I'd probably approach it the way you are. If it was something I was releasing for others to use, I'd make a Fieldtype and an Inputfield. The Fieldtype would have the same schema as the current FieldtypePage schema, except that it would have an extra column for "code", to contain an integer that the user enters. I'd have the column indexed like the others, so that it could be queried from selectors. It would offer a shortcut for querying, potentially faster than querying the page titles of page references. One of the advantages of going the Fieldtype route is that ProcessWire will be managing things like deletions. If you delete a page, then it's going to delete the entries for that page in the DB. If you are managing your own via the Inputfield, that won't happen. This may or may not be an issue in your case. Just depends on how permanent the data is I guess. It could always be resolved fairly easily by adding a Pages::deleted hook. In your case, since the use is so specific I think just developing an inputfield, and storing those codes in your own table may offer a simpler solution. You'd just need to store the pages_id and code. Your render() method would do something like this: // get page being edited from ProcessPageEdit $page = $this->process->getPage(); $query = $this->database->prepare("SELECT code FROM your_table WHERE pages_id=:id"); $query->bindValue(":id", $page->id, PDO::PARAM_INT); $query->execute(); if($query->rowCount() > 0) { list($code) = $query->fetch(PDO::FETCH_NUM); $code = $this->sanitizer->entities($code); } else { $code = ''; } $out = ''; // here's where they enter the code, already populated with the existing value $out .= "<input type='text' name='{$this->name}_code' value='$code' />"; // then your page selection follows For your processInput method, you'd do the opposite... storing the code that was entered. $page = $this->process->getPage(); $code = $input[$this->name . "_code"]; // delete existing value if already present $query = $this->database->prepare("DELETE FROM your_table WHERE pages_id=:id"); $query->bindValue(":id", $page->id, PDO::PARAM_INT); $query->execute(); // insert the new value for code $query = $this->database->prepare("INSERT INTO your_table SET pages_id=:id, code=:code"); $query->bindValue(":id", $page->id, PDO::PARAM_INT); $query->bindValue(":code", $code, PDO::PARAM_INT); // or PARAM_STR if appropriate $query->execute(); Let me know if you want an example of how to do the Pages::deleted hook.

I don't care so much about whether my name is in the admin, but my understanding is that the company name has to be there, and I think it should. My full company name is Ryan Cramer Design, LLC. Very little of my business is design anymore (it's mostly development), so if the context is not one of design, I simply use the shorter version: just Ryan Cramer, or RCD. The plan is to change the company name to ProcessWire LLC, at which time I can change it to say "Copyright 2013 ProcessWire" like the other CMS projects do. The only reason I haven't done it yet is that it costs $ to do that, and I'm not running on a budget surplus at present. I honestly didn't think anyone cared what the copyright line said, so it's been hard to justify that change until I've got the extra cash to do it. Regarding use of a copyright line in the admin interface: the end users of the product (our clients) generally don't see or have any idea how to access the copyright statements in the server-side code/text files. So it should be visible to the actual end-users, with the admin tool they use being the most clear placement. Though I think the laws regarding this may vary from country to country, but I think it's better to just play it safe. Rest assured it will say Copyright ProcessWire at some point in the future.

Yes it sounds to me like there are class name collisions. That won't be an issue once both PW and Fuel are namespaced, but that also doesn't guarantee that the two will run alongside each other either. I do know of people that have used CI and ProcessWire alongside each other, and apparently that works pretty well. But I'm not aware of anyone running ProcessWire and another CMS running on the same request, including files from one another. Though I did once bootstrap Drupal from ProcessWire.