ryan

I agree this should go in the near term roadmap. Though I'm thinking it would just be a warning rather than a lock, i.e. "Warning this page is currently being edited by Soma. You should avoid making edits until Soma is finished." The reason I think a warning rather than a lock is better is because someone may just leave their window open to a page, and we're pretty generous with long session timeouts.

It shouldn't matter where the sort is placed. I have a feeling there's a missing comma in your selector string, because that would make it appear that moving it to the end fixed it (since you don't need a comma at the end). One way to tell for sure would be to echo your selector string to see what is getting sent to PW: echo "$sort$limit$published$cats$id,published=1,pdate<=$today";

Thanks for the continued feedback. Given what I've learned here, I have updated our homepage <title> tag to: I don't think I can go any longer than that before Google will truncate it in the serps. But if anyone has any optimizations to suggest let me know. I think the first half is probably about right, but not sure how audience and keyword-relevant the second half is with "Strong API, Easy Admin (PHP 5)"... that's just my best guess.

Thanks, that's great. I'm actually not disappointed how well the server held up, given that it's a 'entry-level' vps with relatively low memory and resources. It was still serving pages at a load of 50+, though taking about 10-15 seconds to do so. As far as I know, the server never started refusing requests. Though I'm sure its slowness sent a lot of people away or left them with a bad impression. :-\ For starters, I'm going to install a PHP opcode cache (APC), as that should help.

Thanks, I will definitely appreciate your help here. It keeps a separate JSON translation file for each .php or .module file that is translated. Meaning, if you translated a ProcessPageEdit.module, then it would keep a languageName.ProcessPageEdit.json file containing all the translations for ProcessPageEdit (in 1 language). When you edit a page, all the translations for the current language in ProcessPageEdit get loaded. So it's not as memory efficient as loading each phrase translation at the time it's needed, but it is of course much faster. ProcessWire is not very 'wordy' so there isn't actually a lot of translation to keep in memory at any given time. But if memory becomes an issue, the plan is to provide an option for each translation that delegates it as 'always-load' or 'on-demand'. Currently all are 'always-load'. But 'on-demand' would be useful for things like error messages that rarely appear. Perhaps I'll provide this is an optional second boolean param to the $this->_() function that lets you mark a given phrase as 'on-demand' for such cases.

Your setup sounds just fine, though if we can't figure it out we may want to take a look at your phpinfo. If you have a URL with a "<?php phpinfo();" script, please email it to ryan at this domain name. Though first, lets take a look at this: When you see the 404 page, what is the exact URL remaining in your address bar? I think this might help us to determine what is happening. Lastly, can you post the resulting error in your /site/assets/logs/errors.txt , as it would help to get a look at that too.

Ah that makes sense, I guess that's called getting smashed. Despite that, the server is now on the mend (5min load down around 7 now). We just got hit with more traffic than the VPS could make processes for over 45 minutes or so. So I'm a little sad to know we probably turned some people away by being inaccessible. I'm setting up a mirror of the PW demo on processwire.org, though it's just a budget hosting account so not sure how much that'll help. I also need to get some more of the templates cached on processwire.com. I talked with the hosting company about upgrades, but they can't get in the upgrade fast enough to help today. So we'll just ride this one out and hopefully I'll be better prepared or the next time a spike like that occurs.

Hey guys, it looks like we're getting nailed with traffic today. Looks like I need to upgrade the server. I'm going to try and setup a mirror at processwire.org and see what the hosting company can do about upgrading the VPS. But wanted to provide advance warning that the server may go down today as the load just keeps rising (up above 50 right now). Looks like today will be our highest traffic day ever. Just hoping I can keep the server going.

Autojoin is only necessary for fields that you want to have pages automatically sort by (i.e. be selectable from the pageedit 'children' tab for automatic sorting). But autojoin shouldn't be necessary for API usage. At some point I should be able to get rid of the autojoin requirement for automatic sorting too.

Is 'pdate' actually a 'date' fieldtype? (as opposed to a text fieldtype)? Antti is correct that the date input/output format doesn't matter here because dates are stored (and sorted) as unix timestamps. Assuming it's date fieldtype, can you post a larger portion of the code where you load these pages so we can see the full context?

Welcome to the forums and thanks for posting. I always wondered how that person resolved the issue you linked, as I never heard back. This is the only other time I've heard of it, so we might need to test a few things to track it down. Can you edit your /site/config.php and find the line that says $config->debug=false; and set it to true? I'm just wondering if that might help us to get a better error message. What is your server software? (PHP version, Apache version, platform?). What browser and version are you using? Thanks, Ryan

Ah right I forgot about Markdown, but that makes perfect sense. Glad you found a solution there and thanks for the follow-up.

Great, glad that did it and thanks for the follow-up.

I've used Drupal and UbertCart (now under the name Drupal Commerce), and run it alongside ProcessWire (1) so that Drupal and PW share the same user system. It enables a user to purchase a subscription product and then have access to protected content in PW. But as much respect as I have for Drupal, it drives me nuts when I have to use it. So I'm not sure I'd recommend this solution just because it's not so easy to get going on the Drupal side and I regularly battle with it when doing updates. Though prior to that, I'd run OSCommerce for a few years, and UberCart was like a revelation compared to that. So if you need a really strong self hosted commerce solution, I would definitely look at UberCart / Drupal Commerce, but plan to invest a lot of time. Now I'm testing Shopify and experimenting with their post order hooks to create member accounts in ProcessWire (2.1). It's not nearly as powerful as UberCart, but the post order hooks and their 'app store' can fill a lot of gaps. This is a work in progress, so not much to say yet. I like what I see in Shopify so far, but like everything else, it's far from perfect.

That looks like a good one– I definitely look forward to reading that.

Good point–I think you are definitely right about that. I've not put too much thought into it because the eventual names are up to the user. When they add a language, it'll ask them to type in what they want the name to be. But I think suggesting a name format is a good idea. Not to mention, when we distribute language packs, we'll probably want to use the IETF rather than ISO name. Great! Glad it sounds good to you so far. Most of this is stuff you and I already figured out before in those emails a few months ago, so a lot of credit for the solution here goes to you. Though I've not yet covered everything we talked about, but do plan to. I actually have the modules working at this stage, but not yet exactly as described (though close). So part of the purpose in writing it all up was to outline what's already been done and what's left to do. I worked on the multi language capabilities for 3 days straight and have to work in something else the rest of the week so wanted to get it all written down while it was fresh on my mind. Also wanted to get feedback from others that work with multi language systems more than me just in case I'm missing anything major. My experience in this area is somewhat limited, so it's a learning process here. And it may take us a couple revisions to get everything right, but the goal is to provide the best multi language capabilities out there.

Thanks marcin! You all are very kind. Next time lets do all the birthdays on facebook so that I know when all of your birthdays are too. I'm a little embarrassed to be the only one with a birthday here. Add me as a friend on facebook: http://facebook.com/cramer.ryan

I still don't really understand exactly what you mean by the goal, or the GLOW. But it sounds like you are on the right track.

What you are looking for is in this file: /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php Though the process is the same regardless of what module or file it comes from. The render() method sends the output for the form, but it also has a line checking to see if the form has been submitted. Something like this: <?php if($input->post->submit_comment) { // comment was submitted $this->processInput(); } // then generate output Note that this won't work if your page is cached. So you'd either have to disable cache on comments page, or set it to recognize one of the submitted variables (like page_id) as a var to disable comments, or delegate another page dedicated to saving comments.

In your Process module, make the getModuleInfo() function return the required permission to access the module. For example, here's the one used by the ProcessPageEdit module: <?php public static function getModuleInfo() { return array( 'title' => 'Page Edit', 'summary' => 'Edit a Page', 'version' => 100, 'permanent' => true, 'permission' => 'page-edit', // note this line ); } So for the PageEdit module, we've assigned the permission 'page-edit' as the one required to access the module. In your own module, you can specify any existing permission, or make one up. If you make one up, then you'll want to go and add it to your permissions. From there, you can assign that permission to any roles. Any users having that role will be able to access the module.

Your first test (Test A) is what I would personally use, i.e. if($page->summary_de) { ... } Are these TinyMCE fields? I think you need to look at what's actually in the field. I have a feeling you've got some whitespace in there or something like one of these annoying TinyMCE droppings: "<p> </p>" or maybe just a carriage return or couple of spaces. Get the value out of an HTML context to see what's really in the field: echo htmlentities(var_dump($page->summary_de)); If you are dealing with possible whitespace in the field (as opposed to HTML tags or entities) then your if statement could account for that by doing this: if(trim($page->summary_de)) { ... } Don't bother with using isset() or is_null() -- those are really more useful in determining of the page's template carries those fields at all. But I don't think they are particularly useful for what you are trying to do.

Whether to use PW to build this – I'd say Yes, i think it would be a great way to go if you use PW how it's intended. That means using templates to define your data types and pages to contain the entries. Though even if you don't use PW to define and store your data, it still serves as a nice framework for your pages. I'm good with specific questions but get stumped on broad, all-encompassing questions like this. But here are a few 'broad' pointers that work for me when approaching a new project: Figure out the logic you'll need outside the context of any other framework or code. Get a good solid understanding of the big picture in your head, and write down the key points to help you keep it fresh for the long term. Take it one step at a time. If you get stumped on any part, then break it into smaller pieces. Start simple. Get a barebones functional prototype, then go back and make it do everything you want. For instances where you can't or don't want to plan it all out ahead of time, and it's preventing you from moving forward– just start. By that I mean code now and plan later. Then redo it with a plan once you really understand it. Some things need to be figured out as you go, and then you can go back and re-do as necessary to make it right. I'm not sure everyone would agree with this, but it works for me (and I code a lot of things twice or more). In general: Define your goal and understand what the completed goal looks like. Take where you are now, and where the goal is, and break it into 3 major steps to completion. Then break those 3 down into smaller steps until each seems relatively simple. Write down those steps. Accomplish one step at a time. Cross them off the list and keep the momentum going till the goal is completed. In accounting: sorry I don't know about that.

It sounds like there is reference to a field no longer in use in your fieldgroups_fields. Not sure why it would be there, but we need to remove it. Because your new copy of PW won't run at present, It'll have to be done from PhpMyAdmin (or another MySQL client). It sounds like the install actually may have finished, so try this on your new PW 2.1 database, rather than the old one. Open the PW database in PhpMyAdmin, click the "SQL" tab at the top, paste in the following query and click "go": SELECT fieldgroups_fields.fieldgroups_id, fieldgroups_fields.fields_id FROM `fieldgroups_fields` LEFT JOIN fields ON fieldgroups_fields.fields_id=fields.id WHERE fields.id IS NULL; The results will show you any matches that don't belong there. Click the red "x" next to any matches to delete them. Then try to open your site in the browser and see if that fixes it.

It sounds to me like Apache might not be using your .htaccess at all. One way to tell is to edit your /.htaccess file and type a bunch of random characters at the top, like "abcdefghij", save and try to load your site in the browser. If you don't get a 500 error from Apache, then that means it's not reading your .htaccess file. If this is the case, find your apache config file (httpd.conf) and locate the VirtualHost entry for the site PW is running on. If you see an "AllowOverride None" or AllowOverride anything, change it to "AllowOverride All". Save and restart Apache and Apache should start reading your .htaccess file.

I've been making good progress here on ProcessWire 2.2 which we're targeting for the end of the year. The main drive of this version is adding multi-language support to the admin. This multi language support is being sponsored by Avoine, thanks to Antti Peisa. I just wanted to outline the approach we're taking as well as get any feedback and suggestions you have. The direction taken with multi language support is based on conversations Antti and I had a few months ago as well as feedback from users in the forum. What ProcessWire 2.2 focuses on There are lots of components to supporting multiple languages in a CMS, and the area we're focused on with this version is supporting multiple languages for PW's admin, modules and 3rd party modules. This is so that your clients can make edits to their site without having to know English. While PW hasn't had specific multi-language tools for your front end, it can support multiple languages any number of ways there (as many users have done, with language trees, multiple fields, etc). But the back-end tools have always been in English without an obvious way around that. So the biggest need has been a way to support multiple languages for PW's admin tools, core modules, 3rd party modules, etc. Basically, the non-dynamic side. And that's what PW 2.2 tackles. The direction being used We originally looked at PHP's gettext tools (http://www.php.net/manual/en/book.gettext.php), as they've been successfully used to provide this capability for CMSs like WordPress and Drupal, and they are a ready-to-go solution that is built-in to PHP and adds multi language capability with little overhead. I like gettext() from the PHP side as it's a really easy solution (for coding at least), and it's really efficient from the PHP side. But I felt that it puts a lot of burden on the translators with a lot of technical jargon, file formats and other tools. I want the translation tools to have the same simplicity as the rest of PW, and it looked like that was going to be a hard sell with gettext. Instead, we're using a home-brewed solution that essentially does the same thing as gettext, but is a whole lot simpler for translation. It's simple enough that if you find something that needs translation, you can just go and edit it in PW like you would edit anything else. It also means that these tools will be very simple for 3rd party module developers to use. They will also have use in your own sites and templates for your non-dynamic content. The tradeoff is that it takes longer to code this way (for me) and that it can't possibly be as efficient as gettext (given that gettext is built-in to PHP). Translations take up memory. However, PW, doesn't have files with tens of thousands of lines of code and doesn't need to keep thousands of translations in memory at any given time. When it gets down to the needs of PW and the needs of those using it, I don't believe we'd ever benefit from the efficiency of gettext. So the home-brewed solution won out. The actual solution is coded as a module. So if you don't need anything other than English in the admin, then you'll just leave the 'Languages' module uninstalled. How it works from the admin side The Languages module will be provided with the core, ready for a 1-click install. As soon as you click 'install', a 'Languages' tool is added to your Setup menu, a 'language' template is added to your templates, and a 'language' field is added to your fields and appended to the 'user' template with the default language (English) selected. When you go to Setup > Languages, you'll see a list of languages that are installed. From here you can click to edit a language or click 'Add New' to add a new language. Each language is technically a page (just like with users), so you can add additional fields to the 'language' template should it suit your needs. By default, each language template has a name (ISO-639 code, i.e. 'en'), a title (i.e. 'English') and a 'translations' file field. Each file in this field contains translations for a file in ProcessWire (whether a module, core, template, etc.). These files are created by another module in ProcessWire (to be discussed below) but a files field is provided here so that you can easily share your translations with other people. Likewise, you'll be able to download new language packs from the ProcessWire site and just upload them here, ready to use. How to make a translation ProcessWire keeps track of language translations on a per-file basis. So if you want to translate a file in ProcessWire, you have to tell it which one. ProcessWire will then load the file into memory and look for function calls that indicate translatable text. Then it presents you with a screen of all the phrases it found for translation, along with inputs for providing a translation for each one. See the attached screenshot for an example of this. When you hit 'save', it saves those translations in a JSON file that PW's languages module uses for runtime translation. This JSON file can also be shared with others, distributed with a module you've created, or zipped up with others as part of a language pack. As soon as the English version native to the translated file changes, the translated versions are considered out of date. We don't want to make guesses about the scope of the text change. So your translation screen will show you any existing translations that are considered 'out of date' along with new entry fields to provide new translations. Any fields left blank on the translation screen are considered untranslated and thus the original language (English) is substituted for any untranslated phrases. How it works from the code side I mentioned earlier that I like how gettext works from the developer side, and ProcessWire works in a very similar manner in this regard. Meaning, indicating text as translatable involves a "_" function call followed by the text. ProcessWire also needs a context, so you call this function with '$this'. Here's an example: $value = $this->_('Add New Page Here'); So $this->_('text') identifies the text as translatable. You have to use $this->_('text') rather than the gettext format of _('text') for two reasons: first is that the _('...') function is native to PHP and actually calls gettext, so that's already taken! Second is that ProcessWire needs a context to the function call… it needs to know what class or file it was called from, otherwise all translations would be a global namespace. So ProcessWire figures that out behind the scenes with a context of the calling class and uses the Reflection API to determine the file. If you didn't understand that last sentence, then don't worry because you don't need to–ProcessWire is taking care of the technical details for you. In addition to the $this->_('text') you can use a function format that would most likely be more suitable for translations performed in your template files. In this case, because "_" is already taken by gettext, we use "__" like WordPress does. So you can do this: echo __('Submit Form'); ProcessWire figures out the context of that call automatically and groups the translation with others from your template file. This type of call can also be used in 3rd party modules, but you'll have to tell PW the context, i.e. <?php echo __($this, 'Submit Form'); // these two lines do exactly the same thing echo $this->_('Submit Form'); Best practices for pre-translated text Just like with gettext, when entering text that's ultimately going to be translated, you need to avoid putting in any dynamic things in it. For instance, a string like "Found $count products" is not good for translation because it contains a variable in it. Instead, you'd want to enter such a string as: sprintf("Found %d products", $count). For more details, see the 'Marking Strings for Translation' and 'Best Practices' sections in WordPress's i18n page. They use gettext, but the same applies to us: Marking strings for translation http://codex.wordpress.org/I18n_for_WordPress_Developers#Marking_Strings_for_Translation Best practices http://codex.wordpress.org/I18n_for_WordPress_Developers#Best_Practices New API variables The Languages module installs a new API variable called $languages. It's interface is identical to that of $users in that it can be iterated as a PageArray or you can use get() and find() calls to pull individual languages from it, i.e. <?php foreach($languages as $language) { echo $language->title . "<br />"; } …and… <?php $french = $languages->get('fr'); The Languages module also adds a $language variable to every $user. So you can check what the current language is like this: <?php if($user->language->name == 'es') echo "Hola!"; Of course, $language is just a Page object, so it will also contain any other fields you have added to your 'language' template. Because ProcessWire's native language is English, the language is assumed to be English by default. So if you want it to assume a different language by default for your site, then you would just edit the 'guest' user and select a different language. Next Steps So that's the current state of ProcessWire 2.2 and how it's multilanguage support works. But it's not the only part of it. Because ProcessWire's admin is itself a site developed in PW, and because PW's output is not all non-dynamic, we need multilanguage support in our dynamic fieldtypes and inputfields in order to be truly multilingual. This is what I'll be focusing on in November, so will have more updates on that side of it then. Of course, this side may also be useful for the front-end (your sites) too, though my feeling is that a multi-tree approach is better for accessibility and SEO even if you do have multilingual fields. But even with a multi-tree approach, having multilingual fields will no doubt be useful with shared assets and more. I'm also hoping to have a beta version ready for those that are interested in testing within a month (or in the next few days, if interested in testing before multilingual fields are in place). Please post your questions, suggestions, feedback, etc. This is a work in progress and nothing is set in stone. Edit: added 'New API variables' section.