ryan

Any time when I've had behavior like this it's because I was using either template caching or markup caching, and didn't realize I was seeing cached versions. So make sure you are logged in when changing around stuff (or that you aren't using caching). We've also noticed that TinyMCE can store characters in text fields that aren't otherwise visible (even looking directly in the database). I had to go in with a hex editor before I could see the UTF-8 non-breaking space TinyMCE had inserted. So if your text field has been used with TinyMCE at some point, that's something to consider. Table repair is also something to consider when you see strange results. That will cause MySQL to rebuild the index for the table. But I wouldn't expect this to be necessary unless someone has changed a MySQL setting (like ft_min_word_len) and not rebuilt all the database indexes.

AnotherAndrew, when did the problem start? After migrating the site to another server? The fact that you are getting a 404 makes me wonder if this is a different issue than the one Oliver was running into. If the issue just started without there being some big server change, I'd suggest running a repair on your database, just in case. If you have PhpMyAdmin, this is very easy and fast to do.

Arjen, thanks for posting this info. You mentioned that you saw PW a long time ago and clicked away. Do you recall why you didn't stick around at that time? We're going to be putting in a new site design soon, and the more we know about what makes our target audience click away or dig deeper is very valuable.

Oliver, I should have asked this before (sorry): Does your module implement the "ConfigurableModule" interface? ProcessWire doesn't consider it configurable unless it implements that interface. If you are extending the WireData class, it already implements the interface, so all you have to do is change: class MyModule extends WireData { To this: class MyModule extends WireData implements ConfigurableModule { The point of having this interface is so that PW doesn't spend additional cycles looking for and populating configuration data for modules that don't use it (as most don't).

Thanks DaveP-- Glad that you got up and running and are enjoying using ProcessWire! Your compliments made my day, especially what you said about "looking for complexity that wasn't there". I think we're all conditioned to look for complexity in CMSs because most of them are pretty darn complicated once you get beyond doing basic things. If a CMS were a car, you'd have to know how to tune the engine, bleed the brakes and adjust the spark plugs before you could drive it. With ProcessWire we're trying to put you in the drivers seat rather than under the hood. Take development tasks that would be complex and make them a lot easier. If you saw how many iterations all of this stuff has been through, you might say I'm a bit slow. Part of the reason ProcessWire is here is because I wasn't smart enough to be able to figure out how to get things done with the other CMSs.

I think this is probably the best way to do it. That will hopefully prevent the problem that Antti mentioned.

Thanks for checking it out, glad you guys like it so far! Soma what you described is quite similar to how this system works. It literally is creating a system template behind-the-scenes, and each repeatable element is a page. You can have as many repeatable fields, and repetitions of those repeatable fields, as you want. You can even stack them (repeaters in repeaters) though I don't think I'd want to. The pages are hidden outside of the site structure, so you won't see where they are at first. Likewise, the templates are hidden as system templates, so you won't see them in your usual development. But if you want to put in a template file to provide the rendering capability for the items, you can... enabling you to do something like $building->render(); I'm working on a 'detach' capability that lets you move the repeater template and parent into your site structure, should you want to. But this 'detach' capability won't appear in the first version. The reality is, repeaters are more approachable if you don't have to see the technical details of how they work, right in your site structure. But the fact that they can be part of your site structure opens a lot of possibilities, so that's why I've already started work on making them detachable ... it'll make building large sites a lot easier if you can create 100 pages on 1 screen, for example.

I've been working on making repeatable fields for ProcessWire for a couple weeks and actually now have it nearly ready. I need to do some more testing before releasing it, but wanted to give you a little preview. (please view the full screen version for better quality) Accessing repeatable fields from the API is super-easy. They are fully searchable/selectable with the API just as easily as with any other fields. So if you wanted to find all pages that had a buildings field with a floors value of 50 or more, you'd do this, for example: $pages->find("buildings.floors>=50"); Lets say you are on the page with a 'buildings' field and you want to print out all the building names and number of floors. It works exactly the same as page references: foreach($page->buildings as $p) { echo "<p>{$p->building_name}</p> has {$p->floors} floors.</p>"; }

If you wanted all grandchildren, and nothing deeper, you could do this: $page->find("parent=$page->children"); If you wanted grandchildren and anything deeper, you could do this: $page->find("parent!=$page"); If you wanted children, grandchildren and anything deeper, you could do this: $page->find('');

That's a good idea. I will plan to do that.

Thanks Jiserra, I've pasted the ZIP file for the Spanish translation at the URL below. This includes all the current translatable files, many of which don't yet have my fake Spanish translations. But I think this is still the best starting point. If your server supports it, you can just drag the ZIP file into files field when you create the Spanish language page. If not, then you'll have to extract the ZIP first and then drag the JSON files in as a group.

Attached is a ZIP containing the all those files if you'd rather drag in the zip or json files rather than paste in each of the names. These originated with my fake-Spanish translation, so several of the files have the Spanish translation, which you'll want to overwrite with your own translations. spanish.zip I will plan to keep the list above and this file up to date as new translated files are added.

Thanks Robert, it looks like that worked! I renamed the old 2.0 repository and changed the URL with this command: git remote set-url origin git@github.com:ryancramerdesign/ProcessWire-2.0.git I pushed a test commit and it worked exactly as it should. So I will plan to do the same thing on the current P21 repository after I've given people some advance warning of the change. My plan is to rename the P21 to just "ProcessWire" (same name as the old 2.0 repository). Assuming there were others still tracking the 2.0 repository (hopefully not), do these look like the correct commands that they would need to execute in order to track the new one? git remote set-url origin git://github.com/ryancramerdesign/ProcessWire-2.0.git or git remote rm origin git remote add origin [color=#282828][font=Georgia,]git://github.com/ryancramerdesign/ProcessWire-2.0.git[/font][/color]

I don't know why the US date format is the way it is. The d/m/Y format does seem more logical. Maybe the US date format is meant as some kind of calendar hierarchy? The date format I prefer the most is Y-m-d, but mainly because it's string-sortable. You don't necessarily need to go changing settings in your spreadsheet if you don't want to. Another way to convert your d/m/Y dates to d-m-Y (dashes rather than slashes) is to load the CSV into a quality text editor and then use a regexp to swap the slashes for dashes. Here's the search and replace I'd use in TextWrangler (BBEdit): (\d{2})/(\d{2})/(\d{4}) => \1-\2-\3 PHP's strtotime() function treats dates with dashes as European format and dates with slashes as US format. So once you convert those dates in your CSV to use dashes rather than slashes, they should import just fine with the CSV import module.

I think in this case it's because the getModuleConfigData is happening in the same request as the saveModuleConfigData. I'm guessing that if you performed a getModuleConfigData on the next request, you'd see it there. The reason for this is that anything in your config data gets populated to the module automatically when it is initialized. Your module could expect to find a $this->user_roles property locally present on the next request. Once the config data has been loaded, it gets cached. That cache only gets cleared once per page view. So the empty array you are getting is most likely because the old (empty) data is cached, but the new data would appear on the next request. It would make sense for saveModuleConfigData to clear that cache, so you'll see that in the next commit. Since your config data is automatically set to the module when it gets loaded, the getModuleConfigData is something that isn't needed often. getModuleConfigData is mainly useful for modifying existing config data right before you saveModuleConfigData. I also want to add that configData can't have objects in it. So your $this->roles->get('guest') will likely get converted to the ID (number) of the guest role.

This doesn't work because $page->children is an array of pages (PageArray), not a Page. Think of it like a boat carrying a bunch of people. The boat can't have children, but the people in it can. I'm also not sure $page->children->children would be all that useful, because they would have lost all sorting context. However, I'm only thinking in context of the sites I make and know everyone has different needs. So if you want to have something equivalent to $page->children->children, it would be $page->find('id>0'). But I would suggest using Soma's examples as they are more specific to a template, and it's better to be specific. Nearly any search that gets passed through a selector is fully indexed, so it doesn't have to scan the whole site. If you put in "template=video" it [mysql] heads straight to an index of pages with the video template, so it's not scanning or considering other pages. You'd want to limit that if you were using the video template elsewhere in the site and didn't want videos from one branch getting mixed in with videos from another. However, if you know where you are using the video template and aren't going to be using it on other branches in the site, there's no speed advantage to performing the search within a parent $page rather than just using $pages->find() to do it. Technically, there's slightly more [minor] overhead doing a $page->find() than a $pages->find() because it's adding a lookup table to the search that may or may not need to be there.

Robert, what I link to actually isn't the dev branch. I maintain a separate dev branch locally and then updates go into the master branch after I've tested them to make sure they are working properly. If I'm working on something major, I have that dev branch at GitHub as well so people can switch to it to help test. But I get what you are saying about tags and sending downloaders to that. I'm a little mixed about that because I'm always fixing, optimizing and improving things and would hate to send people to something that is something older than the latest stable. But I suppose I could still do that with tags like 2.1.1.2 or something like that, and then update the download link and version number in the source every time I push a commit. This would at least enable more easy communication of exactly what version someone is using when an issue comes up. I'm willing to give it a try. But that leads to a question: how do I get tags to go to GitHub? I added tag "v2.2.0" to PW as soon as I released the version a few weeks ago, but that tag has yet to show up anywhere at GitHub. Yet if I type "git tag" locally, I can see it. Perhaps I haven't attached it to a specific commit? I need to read up on tags. As a test, I renamed the old ProcessWire 2.0 repository from "ProcessWire" to "ProcessWire-2.0". It worked, but GitHub is telling me "unexpected bad things" and I usually try to avoid unexpected or bad things: They are saying "we" will not setup redirects, but they aren't saying it can't be done. It seems like that leaves open the possibility that I can setup redirects somehow? (maybe just wishful thinking?) How do I update my local repository to point to the new location? What instructions should I give others to update their location? I'm going to test this all with the v2.0 repository before attempting with the 2.2 repository. Thanks, Ryan

Actually abstract classes / interfaces are there to help avoid messes. You could get along just fine without them, but using them keeps things in order and lets you make assumptions about objects rather than having to check that they meet some criteria on your own. If you say that something has to meet an interface and it doesn't, then PHP throws a fatal error. That helps to avoid messes before they start. There's not much more to it than that. The terms "abstract" and "interface" sound technical, but luckily the concept is simple.

I think that your naming convention sounds good. You could find all modules like this: $paymentModules = $modules->find('className^=Payment'); However, your idea of using an abstract class or an interface is something I think you'd also want to do. That's because you are going to want all of your Payment modules to adhere to a specific interface so that all will have a processPayment() method, for example. An abstract class and an interface are basically the same thing except that an abstract class can provide some code implementation (functions) and declare other functions as abstract, where the descending class has to provide the implementation. Whereas an interface provides no implementation, it just defines what the required functions will be. Any functions outlined in an interface would be the same thing as an abstract (no-implementation) function in an abstract class. Neither an abstract class or an interface can be instantiated to an object, so they mainly define requirements for other classes that either extend the abstract class or implement the interface. Here's an example: interface PaymentInterface { /** * Process a payment and return true on success or false on failure * */ public function processPayment($amount); } class PaymentModule extends WireData implements Module, PaymentInterface { public static function getModuleInfo() { return array(...); } public function init() { } public function processPayment($amount) { // a bunch of code here to process a payment return true; } } Since the module above adheres to both the Module and PaymentInterface interfaces, we know that it can be used in the situations where we need it. You know it will always have a processPayment() method. So once you've found your Payment modules, you'd want to make sure that they also implement the interface before using them: if($someModule instanceof PaymentInterface) { // $someModule can be used as a payment module }

Glad that you got it working. Those session files don't need to travel with the site, so I would suggest just deleting everything in /site/assets/sessions/ and /site/assets/cache/Page/ when migrating from one server to another. Though if you use the ProfileExporter to migrate, you don't need to do this.

This is really coming along nicely. You have me seriously thinking that I need to switch from UbertCart to ProcessWire (rather than Shopify) for the store that I manage.

That's a good question, thank for asking. I've been meaning to post some updates to this. I've added the new files to the original list, below: Core /wire/core/Fieldtype.php Inputfield Modules /wire/modules/Inputfield/InputfieldEmail.module /wire/modules/Inputfield/InputfieldFile/InputfieldFile.module /wire/modules/Inputfield/InputfieldImage/InputfieldImage.module /wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module /wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module /wire/modules/Inputfield/InputfieldPassword.module /wire/modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module /wire/modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module /wire/modules/Inputfield/InputfieldURL.module /wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module Markup Modules /wire/modules/Markup/MarkupPageFields.module Language Support Modules /wire/modules/LanguageSupport/LanguageSupport.module Process Modules /wire/modules/Process/ProcessForgotPassword.module /wire/modules/Process/ProcessLogin/ProcessLogin.module /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module /wire/modules/Process/ProcessPageClone.module /wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module /wire/modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module /wire/modules/Process/ProcessPageEditLink/ProcessPageEditLink.module /wire/modules/Process/ProcessPageList/ProcessPageList.module /wire/modules/Process/ProcessPageSearch/ProcessPageSearch.module /wire/modules/Process/ProcessPageSort.module /wire/modules/Process/ProcessPageType/ProcessPageType.module /wire/modules/Process/ProcessProfile/ProcessProfile.module /wire/modules/Process/ProcessField/ProcessField.module /wire/modules/Process/ProcessHome.module /wire/modules/Process/ProcessList.module /wire/modules/Process/ProcessModule/ProcessModule.module /wire/modules/Process/ProcessPageTrash.module /wire/modules/Process/ProcessPageView.module /wire/modules/Process/ProcessPermission/ProcessPermission.module /wire/modules/Process/ProcessRole/ProcessRole.module /wire/modules/Process/ProcessTemplate/ProcessTemplate.module /wire/modules/Process/ProcessUser/ProcessUser.module Admin Theme /wire/templates-admin/default.php Note: I've removed ProcessLanguageTranslator, as I was incorrect about it having translatable phrases before. With a name like LanguageTranslator you'd think it would though? B)

Pete, I've added support for page-publish permission. To use it, grab the latest commit and then create a new permission in Setup > Access > Permissions, called 'page-publish'. Once PW sees that there, it'll start to use it. So if you create a role that has page-edit but not page-publish permission, you should get behavior consistent with what you mentioned above. Please test it out and let me know how it works for you. Field-level access is something that is planned, where you can limit edit access to a field by role. But probably not till version 2.3.

It's okay to rename things too. Renaming a field is pretty straightforward, as you can do that right on it's main edit screen. Renaming a template can be done from the 'advanced' tab of the template editor. Renaming a page is done from the 'settings' tab of a page.

I like that feature too, but something we'll probably accomplish with an optional module that bolts on to it. Emails getting fired off every time someone responds to a comment could get out-of-hand on a large comment thread. So it's one of those things that really has to be built very carefully (which we can do).