ryan

Here is a starting point for you. You'd want to paste this into a file called LanguageTranslator.module and place in your /site/modules/ directory. Then go to the modules tab in the admin, and click "check for new modules" and the click "install" for the Language Translator module. <?php class LanguageTranslator extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Language Translator', 'summary' => 'Example of translating languages', 'version' => 100, 'permanent' => false, 'autoload' => true, 'singular' => true, ); } public function init() { $this->addHookAfter('Page::render', $this, 'render'); } public function render(HookEvent $event) { $page = $event->object; $out = $event->return; // only operate on admin pages if($page->template != 'admin') return; $translate = array( // place your translations here, in this format (case sensitive) 'Milk' => 'Leche', 'Beer' => 'Cerveza', 'Bread' => 'Pan' ); $out = str_replace(array_keys($translate), array_values($translate), $out); $event->return = $out; } } You are right about some words being in jQuery, but there aren't a lot so I don't expect it'll be an issue. At first, we'll be focusing on the pages list and editor for language translation. The other parts of the CMS (Modules, Fields, Templates, Access) are superuser-only functions, and thus more applicable to developers than clients.

Thanks drilonb–it sounds like your VPS is closest to the Signature VPS at the company where I have mine. This is what I will upgrade to if we ever start getting 25k visitors a day.

Jan, I've found it's hard to constrain the client's "creativity" in a rich text editor, whether with images, type or anything like that. So I generally prefer to just provide them with an upload field and let my template handle the placement and size of the image. But placing images with the rich text editor is sure handy, in disciplined hands. Short of modifying TinyMCE or the plugins, the best way I can think of to bolt-on this type of responsive image would be to hook into Page::render and perform a live (pre-render) replacement of the image tags with the responsive versions. You might also want to look at a solution like http://responsive-images.com, which operates on the original <img> tag and thus is very portable to bolt in just about any situation. It's quite a nice system the author has built. The only big compromise with this (and other similar solutions) is that they don't use the <noscript> solution we were talking about earlier. As a result, the browser is actually loading both large and thumbnail images and swapping in one or the other. The bandwidth consumed is greater than if you just loaded the large image itself. So simple CSS resizing may be more efficient, depending on your need. But certainly the browser will feel faster when displaying the small version (at least, after both images have loaded), and I think that's the real benefit for solutions like that. The benefit of the <noscript> solution discussed in this thread is that it doesn't have to load both images–a major advantage on mobile and low-bandwidth devices. But the disadvantage is that it requires a <noscript> tag in addition to an <img> tag, so it's not as easily plugged into existing situations, like a rich text editor.

I don't recommend changing words directly in the source code, just because that will make it difficult for you to perform upgrades... you'd have to redo your work on every upgrade. A better temporary solution is to build a module that hooks into Page::render, and then just perform a search/replace on all the words you want to translate in the admin. This is relatively easy to do, and I'll be happy to get you started with it if it's of interest. The actual search/replace works like this: <?php $translate = array( 'Milk' => 'Leche', 'Beer' => 'Cerveza', 'Bread' => 'Pan' ); $out = str_replace(array_keys($translate), array_values($translate), $out);

Great suggestions drilonb! If I recall, some of these MySQL settings might be different depending on what hardware resources the server has. What type of VPS you are using to handle 25k daily unique visitors? For instance, processwire.com is using an Essential VPS (lowest cost one) from here: http://www.servint.com/vps.php – Which of those packages does your VPS most closely line up with? Thanks, Ryan

I can't seem to duplicate this one locally yet. What browser are you in?

You could hook into $page->render() and replace the <img> tags with the responsive version. Though I'm not sure I'd bother with inline wysiwyg images because you aren't really dealing with predefined sizes here like you would be outside of it. If responsive images in this context were a really common need, I would probably just code the image plugin to output it in the manner we needed, with noscript tags. But I don't think it's quite common enough to warrant providing that option, yet. I would be more inclined to take a CSS percentage resizing approach for less defined images like those in a wysiwyg field.

Where did you find that link? (must be the search engine?) Someone was working on tutorials awhile back, but I don't think he's finished with them. They aren't officially posted on the site (reason for the 404s), but looks like I've got them set to be searchable. I should probably make them not searchable. I'd forgotten these tutorials were there, I'll check in with the guy that was working on them before I do anything.

Svetlana, welcome to the forums and thanks for posting. While it's possible to use the FormBuilder module (see Modules forum) to build things like contact forms in your site, it's also not intended as a complete solution–more a starting point and proof of concept. Though if the needs for your form are relatively simple, it is a good solution as is. Currently, when I build forms in my sites, I usually build them the same way as if ProcessWire wasn't there – using traditional markup (HTML), Javascript for client side validation, and PHP for server side validation. I like the flexibility of being able to build my forms this way. Basically, you can use whatever method you want to to build your form, and don't necessarily have to consider ProcessWire unless you want to. A complete form builder is planned following ProcessWire 2.2, so we will be providing a lot more in this area down the road. This form builder will be much broader in scope than the current FormBuilder module.

Pete, definitely looks like a bug to me. Are you seeing this on all instances, or just some? Is the behavior is presenting itself randomly or consistently?

Since you are on a dedicated server, sometimes the MySQL installations are very much "default" setups and not really optimized to the server. So there may be benefit in tweaking various aspects of it. But assuming your server load and memory usage is not pushing available resources, you should be able to let MySQL use more of those resources. However, it would be good to double check the memory especially and make sure you've got enough. You mentioned 4000 unique visitors (I'm assuming over 1 day), but how many pageviews? The pageviews are probably going to give a better indication of how much traffic the server is having to deal with, and whether they occur in spikes or are spread out evenly over the day. I recently assisted a friend with his WordPress installation, and his daily unique visitors was similar to yours. The cheap hosting account it was on was constantly getting those MySQL errors, so we moved it to a dedicated server. Even the dedicated server could barely handle it. We ended up installing W3 Total Cache for WordPress. That particular cache can completely eliminate WordPress from handling most requests and deliver everything with static files (through some htaccess trickery). (I'm sure we'll have something similar for ProcessWire eventually.) That solved it in this case with WordPress. But I thought it was interesting to note that this traffic level appears to be at the point where an entry level dedicated server may no be enough. So even if you are on a dedicated server, it may still come down to needing more hardware resources on that actual server to handle the traffic spikes.

Thanks, good post! I think others will definitely find this helpful. Since you are migrating from another site. If you wanted to retain the dates of the original comments, converting from their string format, you could do this: $c->created = strtotime("2011-04-09 15:14:51"); Also, I think you can probably skip setting the ip and user_agent, unless you've got that info you want to keep from your previous comments system. Those are used primarily by Akismet and other spam-detection services, and aren't really needed in your case. Lastly, you can skip setting the created_users_id, because PW will set that automatically according to whoever is logged in when the comment is saved. Thanks, Ryan

I'm not sure that it matters what's on your homepage–it looks like you are running up against the allowed number of connections to your MySQL server. You can try enabling the cache for your homepage, but that just speeds up render time, it doesn't eliminate the fact that there is going to be 1 MySQL connection per person hitting your site. And your web host doesn't allow the number of connections that your site is getting. If you are on a fairly inexpensive hosting plan, this might be a good reason to upgrade. If you are already on a high end hosting plan (or VPS) then I would ask them to increase the number of allowed connections.

Christian– Welcome to the forums and thanks for your post. Glad that you like PW so far. Once 2.1 full release is done, multi language support is next on the to-do list here, and it's the main drive of version 2.2. We certainly welcome any help with translation and testing–thank you for your offer.

It sounds like you've got a multi-file field rather than a single file field. You can fix this by either changing it to a single file field (by setting it to contain a max of 1 files in the field settings). OR you can change your code to this: <?php echo $page->fileuploadss->first()->url; Here's how you might display her description, assuming you are sticking with the multi-file field. <?php $her = $page->fileuploadss->first(); echo "<img src='{$her->url}' alt='{$her->description}' />"; echo "<p>{$her->description}</p>";

If it's something that you need to implement right away, then you may be better off to go with the other method that you linked to, as that will work in either version. It is ready for production purposes, but not yet in it's first official release version. In addition, the upgrade script is being developed as a separate project targeted for September, so you may want to stick with 2.0 a little longer. I also want to clarify that you don't necessarily have to upgrade. I won't be upgrading my existing 2.0 sites unless/until the client wants to do something that only 2.1 can do. If any major bugs turn up, the 2.0 source tree will still be updated.. it just won't have new features added to it. If you decide you want to upgrade, let me know as I'm looking for testers of the new upgrade script. Of course, you'll only want to perform this upgrade in a non-production environment where you can test everything and easily revert if any problems appear. Looks like a very well produced site! Be sure to post in the Showcase forum once officially launched so that we can add it to our site directory. Very nice! Sounds great! Thanks for the kind feedback. I've been developing PW since 2003 (though under the name Dictator before), and has been and will continue to be a long term project here. Nearly all of my client work uses PW, so the project has always been one that will continue to be developed regardless of whether other developers are interested in using it or not. But the fact that so many have taken interest in it is definitely a big motivator to make the project better and better. Version 2.1 is the first version driven largely by the input and help of the PW community, so I'm very excited about that. Thanks, Ryan

If specifying a remote URL doesn't work, this is most likely why (from php.net): Some hosts have allow_url_fopen disabled for security reasons. You may be able to specifically enable it using whatever method your host provides to let you modify the PHP settings.

That is still a good approach, but here is another you can take that's a little simpler (if it suits your needs). You would want to be running the latest commit of 2.1 for this. 1. Create a new role in Access > Roles. Name it "distributor" (or whatever you want). Add only the "page-view" permission to it. 2. Create a new template that will run on the password protected page(s). On that template's "access" tab, uncheck the "guest" role, and check the "distributor" role in the "view pages" column. Also on the "access" tab, in the field labeled "What to do when user attempts to view a page and has no access?" – select "Show the login page". (Also, just a note in case you change it: on the "URLs" tab, URLs must be set to end with a slash [which is the default setting]. This is required for templates that use a login.) 3. Create your password protected page(s). Select the template you created above as the template for this page. The page is now password protected. 4. Create your user(s) that will have access to this page. Give them the "distributor" role. 5. Your done. When someone hits the URL to it, they'll get a login form. Upon completing a login, they'll see the password protected page.

I would say that it's not about being keyboard centric at all. Just a side effect of starting on computers back before there were windowing interfaces. Grew up on a terminal interface rather than a window interface. For me, it doesn't translate to a preference for keyboard commands in a windowing interface at all. I better check my hd smart state then! But it sounds like my computer is running relatively well compared to what you just described. I'm not going to attempt a from-scratch install with Snow Leopard unless I have to. Despite feeling a little slow, my computer is incredibly reliable... it never crashes. And I only reboot once every few months, and not for stability reasons. I suppose I can't complain. Unless they are running on a Windows virtual machine on your Mac. The browsers I run in WinXP on my virtual machines are dog slow... But maybe that's because I'm giving WinXP as little memory and HD as possible. Ironic given that Firefox become popular as a result of being no-bloat, lean and mean. Now it's Chrome that carries that honor. But I still love Firefox for it's source viewer, Firebug, and various addons that are really hard to beat.

Pete, we must be on the same wavelength because I actually added this feature to the P21 source yesterday. See the latest commit. In addition, you can also specify multiple 'required parent templates' should you want to. For instance, if you only wanted it to be possible to add news-item pages below a news-archive page.

Thanks Soma, good post! A couple things to mention: 1. You need to save a page before adding files to it. So you'd want to have another $p->save() before the part where you add an image. This is because in order to place a file in the page, it needs to exist on disk first (so that it has a place to copy the image to). Before you save a page, it only exists in memory. Though if you found that actually worked, let me know–maybe I found a solution in a late night coding session and forgot about it. 2. To add a single image, you'd need to do $p->image = 'path/to/image.jpg'; rather than $p->image('path/to/image.jpg'). This is because there is no Page::image() function. I updated your post for this. 3. For others looking at this code sample, you may need to add a $page->setOutputFormatting(false) depending on the context and if PW gives you an error about needing to turn off output formatting.

It definitely sounds like a UTF8 issue. Here's another possible solution: http://processwire.com/talk/index.php/topic,138.msg2406.html#msg2406 I'm thinking about just placing that 'AddDefaultCharset UTF-8' to the default htaccess file so that this doesn't come up for anyone else. Though I'm not certain that's the problem here. If this solution doesn't do it, I'm guessing Akseli may be running an older 2.0 version that still had some latin1 tables in it and need to be converted to utf8. Akseli what version are you running? Thanks, Ryan

Google that freezer trick first just to see what other people say, because it's been quite awhile since I read about it originally. I tried it on an unmountable SD card, and it didn't work for me. But at least made me feel like I'd tried everything. These MTBFs are in lieu of a manufacturing or materials defect I think. Also, my opinion is that most don't pack their drives for shipping very well (especially Amazon) and the shipping process isn't very friendly to delicate electronics. I'm not very disciplined about backups, so eventually came to the conclusion that I needed something to do it for me since I would never keep track of it. As a result, I've got software running in the background that just keeps things backed up automatically (Time Machine, though I know similar software is available on Windows too). I think that's the only way to go, things are backing up to another drive and you don't have to think about it. For those times that I actually do think about backups, I make a bootable clone of my hard drive (every month or so) just so I've got a somewhat recent starting point.

Thanks for your thoughts on this, I think this was a good digression! I've never really taken much time to customize OS X and perhaps that's the problem. But don't get me wrong, I'm quite happy with the platform, but I'm one that was always happier at a command prompt than a windowing system. Though it's difficult to do graphic design from a command prompt. I'm running Photoshop CS3 on OS X 10.5.8. I have a Snow Leopard CD sitting in front of me, so probably going to install that over the weekend (given that it's a prerequisite to getting Lion). I'm running on a quad core (2x 2.8 ghz xeon) Mac Pro with 6 gigs of memory. I've had it for a few years and it used to seem so fast, but now it just seems unbearably slow... for example, typing a URL into the Firefox 5 address bar appears a few seconds after I type it. That kind of slowness is consistent across pretty much everything (though Firefox is a little worse). Yet looking at the results of 'top' I'm barely pushing the CPU or the memory. I'm going to start by upgrading the OS and hope for the best. I'm tempted to give the touchpad a try, as I quite like using the gestures on my MBP.

I think that makes sense, I've added it to the list: https://github.com/ryancramerdesign/P21/issues/28