ryan

If you don't find someone that wants to do it as a paid job, post more details in one of the other boards and we can help you figure it out on your own.

You'd have to get into tens of thousands of pages, if not more, before you would be able to detect a speed difference. That's been my experience at least. MySQL has apparently optimized their LIKE terms very well, or have figured out how to optimize to an index when it's there.

All modules now have their own short URL off mods.pw. The letter combo used is the base 62 value of the module's ProcessWire page ID minus 1000. For example "3y" translates to 1246. Just a way to keep them as short as possible.

I don't think that many have done this, so we can't say for sure what the issues might be. One that I am aware of is a name conflict between WordPress's gettext() functions and our language functions. Though not sure if it still matters if you aren't using multi-language.

Double check that all of your module files in /site/modules/ are getting copied over. I've experienced a similar error on occasion when I copy over a site, but forget that some of my stuff in site/modules/ was actually symlinks to a shared modules directory… and the modules didn't get copied over to the server. Also, if you aren't copying over the /cache/ and /session/ folders, then at least make sure that you at least re-create these folders on the server and make sure they are writable.

The only reason the default profile uses a head (header) / foot (footer) naming convention is because this is what WordPress does, and it's not far off from what Drupal does. So the point is to provide some point of reference relative to other systems. It's not really the best approach to use once you know what you are doing… though it's also fine to use if it suits your needs.

Regarding Approach #1, I think you'd want to use the LanguageSupportPageNames module included with PW 2.3.0 dev branch. I'm responding to your special cases with that context: You have checkboxes next to each language page name. This controls whether the page is published in each language. There is no need to keep track of this since the URL structure dictates the language. This also makes it very SEO friendly. ProcessWire takes care of setting the user's correct language for you, based on the URL. That's what code internationalization is for. For example, an editable footer: <p id='footer'><?php echo __('Thank you for visiting. Copyright 2013 by Somebody.'); ?></p> The following is replying to approach #2, separate trees: The structure is up to you. Whether or not you start your root with an "en/" for your default language is based entirely on how you structure your site. So if you don't want to have "en/" (for example) for your default language, then don't built off a page called "en". Also not necessary since structure would dictate language. You would examine the $page->rootParent to determine language and set it at the top of some common include file (like a head.inc or init.php): if($page->rootParent->template == 'language-home') { // or whatever your template is called $user->language = $languages->get($page->rootParent->name); } else { $user->language = $languages->get('default'); } The same about code internationalization above applies here. Anything static text you put in a __() function becomes translatable. If something is translatable then it is also editable, even for the default language if you want. If you still didn't want to have text originate from the template, then you could always create a settings page in each tree. I would probably just add my "footer_text" as a field in the language-home page.

Update to the last post– I am adding this validation check to FieldtypePage so that the above won't be necessary in PW 2.3.1 and higher (it will throw an exception).

I think you've got it right. Because a removeAll(); is an action that is ultimately reflected in the database when the page is saved (rather than when you called removeAll), it's a good idea to do that save() after the removeAll() so that it's not getting mixed in and potentially voiding the other operations. Also wanted to recommend adding validation to this: $page->invoice_terms = (int) $input->post->edit_status; Something like this: // using find rather than get ensures the item is retrieved with access control $item = $pages->find((int) $input->post->edit_status)->first(); // double check the item you are trying to add is what you expect by checking // something like the template or the parent, etc. if($item && $item->template == 'your-expected-template') $page->invoice_terms = $item;

Also, you don't need anything more than this: foreach($page->side_bar_widgets as $widget) echo $widget->render();

Your children() operation is just finding the pages that have at least one repeater item that matches the criteria. So you are doing the right thing by performing another find (or foreach) on the result. Just to rule out any possible localization, date conversion, or ProcessWire version issues, try replacing your 'date("Y-m-d");' with just 'time();', for both queries.

Do you see posted comments on the backend? Try moving your renderForm(); somewhere before any output occurs, and stuff the result in a variable that you can output later. For example, try this somewhere before any HTML output: $commentsForm = renderForm(); Then in your comments rendering: <div class="comments"> <?=$page->comments->render(); ?> <?=commentsForm ?> </div> <!-- /comments --> Not sure this is ultimately necessary, but it might help to isolate the issue.

Why not just put both in posts.php? I think it could be confusing to separate tags across files. Since you just want to wrap the pagination, I think what you want is ultimately this line in /site/templates/blog.inc, function renderPosts(): // if there are more posts than the specified limit, then output pagination if($posts->getLimit() < $posts->getTotal()) $out .= $posts->renderPager(); change to: // if there are more posts than the specified limit, then output pagination if($posts->getLimit() < $posts->getTotal()) $out .= "<div id='your-div'>" . $posts->renderPager() . "</div>";

Actually $file->basename is there too. It's the same thing as $file->name. The $file->name is mainly there for consistency with other PW objects, in that we want everything in ProcessWire to reliably have a 'name' property. But I usually use $file->basename myself.

When I post code in here, I'm usually writing it in the browser. That means it's a starting point that may need testing and debugging, rather than a full working solution. Those error messages should help to get to the bottom of it, but I think we need to see the code that is actually in use. Can you post or paste the file here?

I've been working on something similar recently too. Let us know how it goes and if you run into any issues.

LanguageSupport is a core module and has to be upgraded with the rest of the core. So make sure you are replacing your entire /wire/ directory, and not just /wire/modules/LanguagesSupport/. Most likely you didn't see the checkboxes because they are a component of InputfieldPageName. But don't just go upgrade that module–upgrade the entire core.

I haven't tried this module with languages support, but thanks for letting me know that they are not compatible. You should be able to retrieve the $languages API variable via the wire() function, i.e. wire('languages') or wire()->languages are both valid syntax. $languages is a PageArray and can be iterated. Multi-language field types implement FieldtypeLanguageInterface. If you wanted to find all multi-language fields in the system, you could do this: foreach(wire('fields') as $field) { if($field->type instanceof FieldtypeLanguageInterface) { // this is a multi-language field } } Something else to mention about multi-language fields (all of which are text-based, currently) is that their value is actually an object of type LanguagePageFieldValue, rather than a string of text. Its __toString() value is reflective of the user's current language. When outputFormatting is on (as it is on the front-end), it is converted to a string automatically. But when outputFormatting is off (as it is in the admin) the value is a LanguagesPageFieldValue object. There is also another type of multi-language field known as a Multi-language alternate field.These are quite a bit simpler in that they are just a regular field with any fieldtype. But they are recognized as multi-language by name convention. If you have a field named "myfield" and another named "myfield_es", and you have a language installed named "es", then "myfield_es" is assumed to be the Spanish version of "myfield", while "myfield" is assumed to be the default language version. On the front-end (outputFormatting on) ProcessWire knows to substitute one for the other when the user's language matches the field name. If there is a lot of code involved in configuration of an autoload module, then I prefer to put it in a separate file so that it's not taking up any memory for the non-admin requests that don't need it.

I think I understand the request, but feel this probably belongs as a module since it such a specific need. My opinion has always been that the core should only have features that would be regularly used in at least 30% of installations. Otherwise we run the risk of having too much, over-configuration, etc. There are actually some modules we now have in the core that aren't used in at least 30% of installations (anyone ever used FieldtypeCache or some of the lesser known Textformatter modules we include?), so these will likely be moved out of the core in an upcoming version of PW. When it comes to meeting specific needs, I prefer to update the core to add new hooks where necessary (for modules) rather than adding new functionality or configuration. I think your case is one that does sound like a useful capability, but I'd prefer to assist you in implementing it as a module rather than adding it to the core. I'm sure some others will find it useful too, so would like to see it in the modules directory too.

Whenever I run into strange errors like this, I clear the APC cache. And it usually fixes it. It sounds like that probably wasn't the issue in your case, but I have found that APC (or other PHP opcode caches) occasionally get confused and need to be cleared.

JqueryWireTabs also has an associated JS and CSS file, so you'll want your template to include those: <?php $modules->get('JqueryWireTabs'); ?> <link rel='stylesheet' type='text/css' href='<?=$config->urls->JqueryWireTabs?>JqueryWireTabs.css' /> <script src='<?=$config->urls->JqueryWireTabs?>JqueryWireTabs.js'></script> Or you can do this, since JqueryWireTabs populates $config->scripts and $config->styles with the right entries (as do most PW modules that use CSS/JS): <?php $modules->get('JqueryWireTabs'); foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script src='$url'></script>"; ?>

Something to add to WillyC's example is checking whether the given page is active for the language. This is only necessary if you are selectively having some pages published in one language and not in another (meaning, you are using the "active" checkboxes to the right of the language-specific page names). echo "<ul>"; foreach($languages as $language) { if(!$page->viewable($language)) continue; // check if page not published for this language $class = "$language" == "$user->language" ? "active" : ""; $url = $page->localUrl($language); echo "<li class='$class'><a href='$url'>$language->title</a></li>"; } echo "</ul>"; The only change I added above was the if(!$page->viewable($language)) continue; That makes it skip over languages that aren't published for $page. If that check weren't there, then the user would just see a 404 page when attempting to view in the unpublished language.

The only two of those that are PHP functions are dirname() and basename(). As far as I know, filename() and extension() are not PHP functions? So I'm not sure what you mean when you say "emulation of PHP's filename which returns the basename without the extension"? But I think I can tell you how to get the result you asked for of "basename without extension": echo basename($file->filename, '.jpg'); // substitute .jpg with extension you want to remove.

It's not a bad idea to throw a 404 in that condition. Though the only way someone could access such a page is by manually editing the address bar URL. But if you want to account for it, here's how you could do it: $results = $pages->find("your selector goes here"); if($input->pageNum > 1 && !count($results)) throw new Wire404Exception();

See the custom options reference on this page: http://processwire.com/api/modules/markup-pager-nav/ Though if you are just trying to wrap the pagination with a div, then you could also just wrap the output that it returns to you. The FieldtypeComments::findComments() function was added in 2.2.9.