ryan

Pete, since I still can't duplicate here, I'm wondering if there may be some other module involved. What non-core modules do you have installed in PW? Btw, I tried in FF5 not FF6, and IE8 rather than IE9, so will try in FF6 tomorrow, just in case there's something there. Also, can anyone else duplicate this? Thanks, Ryan

Assuming I'm reading it right, I think the only thing that seems different here is the classes you are applying on the opened 'Contact Us' link. What do those classes "dir rtl" mean in terms of how they should affect the behavior of this nav? Thanks, Ryan

If you are starting a new site I would go ahead and use 2.1. But since we're still wrapping up some details, you would just want to test any changes locally (stage them) before pushing to your production server. However, that workflow applies regardless of version or CMS, so if you are using best practices with your workflow then use 2.1.

@MattWilcox–thanks for your posts here. It sounds like the solution you've put together is intended to only send the target image size, rather than the result I was getting (both large & target). When exhibiting the intended behavior, it seems like this would be ideal especially for the situation we were talking about (images in a richtext field). My other concern about a similar approach (from another site) was the security of creating any number of resized images... filling up the drive. But yours only outputs predefined sizes, so that is great. @kunane–given that I recommended this as a possible solution [with reservations] even when I thought we had to live with both images coming through, now I would definitely recommend this solution [without reservations] for the question you had. Here's a few impressions about the different solutions. I don't think I would use both solutions together. If you are using Matt's solution already, I don't think it would be worthwhile to use the <noscript> solution with it because all the JPG requests are already going to be routed through Matt's PHP script (unless you exclude certain dirs). My impression is the <noscript> solution may be one to consider in cases where you have markup control (like in PW templates), already have full image size control (again, like in PW templates), want no server overhead (routing image requests through script), don't want to install anything, and/or want to be able to fine tune the various sizes used in a per-image basis. The <noscript> solution may lose some of it's convenience outside of a system like PW, because you may have to manage the various image sizes manually. Matt's script takes that role if your site is compatible with globally predefined sizes, which could be really convenient. That's my impression based on what I know so far, but I've not used any of these techniques on a production site yet. What are the other situations where you would use one solution over another?

Since you guys need this sooner rather than later, I'll put it higher up in the priority list. Cloning a page will be relatively easy. Haven't tried it, but I think this may work: <?php $cloned = clone $page; $cloned->setIsNew(true); $cloned->id = 0; $cloned->name = $cloned->name . "-clone"; $cloned->save(); Assuming that much works, what I can say for certain would not work is file fields. This is where the process would become more complex than this, though shouldn't be bad. I'm adding this to the to-do queue on GitHub. Adding another tab (like a 'language' tab) to the PageEdit screen is going to most likely involve hooking into the ProcessPageEdit::buildForm function and appending another InputfieldWrapper to the form it returns. Probably best for me to setup an example for this–let me know when you are at the point where you want it and I'll get it going. Thanks, Ryan

The images/files really aren't meant to function independently of a page. All of their ownership comes from a page. As a result, I would suggest maintaining a page for each image, and PW is designed for this. For instance, you wouldn't want an image field to have 1000 images on it because that's going to be really difficult to manage without pagination and such. But if you are using pages as images, no problem. To put it another way, pages can scale indefinitely, but file/image fields aren't intended to at present. As for keeping track of which admin user uploaded a particular image/file, that certainly makes sense. Though it also makes sense with any kind of field. The current plan is that we'll be keeping track of this stuff with a page revision manager and logs, so that you can have a history of all page edits and be able to see where every edit came from (and revert to it if you want). This is actually already functional, but hardly production ready so I'm continuing to work on it and targeting it for v2.3. Be cautious dealing with public data input, especially files. PW isn't designed to have it's admin tools exposed to untrusted users. The needs for anonymous/public data input are different from admin input. For instance, image uploads really need to have original files quarantined (not web accessible) and only processed/resampled versions of images web accessible. Yet this would be a counterproductive approach for admin needs. PW's fields are designed for administrative and trusted users. Uploaded files go right into the /site/assets/files/ directories and not into a quarantine area. As a result, when I'm implementing some kind of public file upload on a site, I usually write the code for that with security specific to the need–it usually involves a quarantine area and babysitting the uploads.

I think that makes sense. If they've specified certain child templates as allowed in the template settings, then I think it should follow what ever order they've specified. Whereas alpha order makes sense if they haven't specified anything. But since the order is sortable in that part of the template editor, we might as well retain it. I've added this to the GitHub issues list. Thanks, Ryan

Those tabs are being generated by javascript from the existing markup. The tab label appears in the 'title' attribute of markup like this: <li class='InputfieldWrapper ui-widget' id='ProcessPageEditContent' title='Content'> As a result, I would maybe suggest a search: id='ProcessPageEditContent' title='Content' Replace with: id='ProcessPageEditContent' title='Inhalt'

I think we'll have to build a module to provide this functionality in the near future (or include it as a configurable option in the PageEdit module, if necessary). I've run into the same need a few times when adding a bunch of pages. It would be nice to just create one right after the other. At the same time, I don't really like having a control like that permanently fixed to the interface like it is in modx. So I think we'll make it something that the powerusers can enable when it suits the need.

Glad you got it working. It's pretty unusual for a webhost running PHP5 to not have JSON support, as it's part of PHP's default installation–they would have to specifically disable it. But I know there are some that install PHP and basically exclude everything possible... that usually means bigger problems than just missing JSON support. There are workarounds for missing JSON functions. You can always define your own json_encode/json_decode functions and solve the problem that way. A good JSON library is the one included with the Zend framework. Years ago I dealt with a client's server that didn't have JSON support, so used Zend's framework and created the functions that way. It works, but much better to have them native in PHP (faster running).

Thanks Pete! I did the same thing before our little one arrived–got as much work done as possible. My work hours pretty much got cut in half afterwards. But it's definitely worth it. I just like to keep up with the forum as much as possible. I don't like killing anyone's momentum by making them wait days for an answer on a simple question. Luckily I've got a few minutes at the computer this morning, so hoping to get caught up.

Several new messages I want to reply to came in since Friday night here. Apologies I've been unable to reply yet. My wife and daughter are very patient with me during the week, but don't like me near the computer on the weekend. So I've been reading on my phone but can't properly reply till back in my office at my computer. So thanks for being patient with me this weekend and I'll reply by Monday (or tomorrow if anyone takes a nap at my house) I just didn't want anyone to think I was ignoring their message--my computer access is just limited on the weekend, some weekends more than others.

Sorry I haven't actually made it back to computer yet, just on cell and hard to type on this looks like I've got lots of msgs to catch up with hope to get back in office later today to catch up

Looks cool–I will reply a bit later, getting called to dinner.

I see what you mean about those class names. I had forgotten those class names were generated dynamically from the text labels. We will need to change that for future localization, so I went ahead and changed it now. If you grab the latest commit, it now keeps the label used for generating the class name in a separate field in the JSON so that you can safely change the 'name' one on the fly.

I'm pretty much getting the same result there. Clear cache and cookies, open tiny browser to the other demo URL. First load is a big 1-megabyte image. Hit reload and it's is a smaller 78k image. First and second load screenshots attached. Are you getting a different result? I was confused by your screenshot, because one of them did show the 205k image as being loaded, so wasn't sure what you meant?

I tried in Firefox this time with Firebug. Cleared my cache and cookies. Then loaded it, ensuring the browser window was as narrow as it would go ahead of time. Got something really interesting this time–830k for creepy.jpg! Not sure what that's about? That can't be right. Maybe a typo by Firebug or am I reading this incorrectly? (see 1st screenshot) Reloading again gets me the normal 205k image (2nd screenshot). My browser window was set at the smallest width it would go the entire time (see screenshots).

Just in case you need it more specific, here's an example of the JSON output (pulled from Firebug). I underlined the Edit, Move, View, and New, so that you can more easily see what's around it. {"page":{"id":2,"label":"Admin","status":1039,"numChildren":6,"path":"\/processwire\/","actions":[{"name":"Edit","url":"\/celist\/processwire\/page\/edit\/?id=2"},{"name":"View","url":"http:\/\/localhost:8888\/celist\/processwire\/"},{"name":"New","url":"\/celist\/processwire\/page\/add\/?parent_id=2"},{"name":"Move","url":"#"}],"addClass":"PageListAccessOff","type":"System"},"children":[{"id":3,"label":"Pages","status":21,"numChildren":8,"path":"\/processwire\/page\/","actions":[{"name":"Edit","url":"\/celist\/processwire\/page\/edit\/?id=3"},{"name":"View","url":"http:\/\/localhost:8888\/celist\/processwire\/page\/"},{"name":"New","url":"\/celist\/processwire\/page\/add\/?parent_id=3"},{"name":"Move","url":"#"}]},{"id":22,"label":"Setup","status":21,"numChildren":3,"path":"\/processwire\/setup\/","actions": ... and so on...pretty isn't it? In your case, you may want to target strings like: "name":"Edit"

You are right it is generated by javascript, I wasn't thinking about that. But it's delivered to Javascript by ProcessWire in JSON format, and that JSON should still pass through Page::render. So in this case, if you set your replacements like "Edit" and "Move" – including the double quotes, I bet that will work. Let me know?

The 'Move' and 'Edit' issue are likely the same thing. Because those terms appear elsewhere in other contexts where it shouldn't be changed, you have to adjust your string to ensure you are only targeting the right version. For instance, with 'Move' and 'Edit', you may want to change them to be '>Move<', and '>Edit<' so that you are only replacing those strings when they appear in a markup tag. You may need to take this approach with most terms. Make them as specific as possible just to ensure you are only replacing the things you want, and nothing that you don't.

My experience so far is that this method doesn't save any bandwidth, it actually increases it. Here's one way to test: 1. Open Chrome (or Firefox, or any browser where you can monitor activity). 2. Open the browser activity window. In Chrome that's: View > Developer > Developer Tools > Network 3. Size your window to as small as you can, to ensure it targets the smallest image size. Then load responsive-images.com. 4. Watch your activity window. Notice that the browser downloads both the large 205k image (/content/images/creepy.jpg) and the 26k thumbnail (/content/images/thumbnails/thumbnail.jpg), even though only the thumbnail is ultimately displayed. 5. Click in some of the other thumbnails and notice that only the large image is loaded (though seems like they could fix that part though, since it's JS driven). Try loading the site on your mobile device (outside of wifi) and notice how long it takes to load–it appears be loading the 200k image, though no activity window to confirm it on my iPhone. The reason it loads both the large and small is because the browser starts downloading the large image as soon as the <img> tag appears, before JS can change it. My impression is that there is no way to avoid consuming the bandwidth of the image present in the src attribute of an <img> tag, unless it's contained in a <noscript> tag.

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);