ryan

Thanks for the followup and details on how this is going SteveB. Glad to hear it's going well and sounds like you are having fun with it too. You mentioned using a template engine–which are you using, or are you using the TemplateFile class? Glad to hear you like (or will like) the new conditional autoload features. I think that passing your own variables through the $page object is a fine way to go. But wanted to mention that the $page->render() method now accepts an array of variables you want to pass to the template file that gets called, and it can be accessed in the template file via the name $options. Not sure if this is useful in your case or not, but wanted to mention it.

Sounds to me like you might have max width/height settings defined in your images field (Setup > Fields > [your image field] > Input). If that's not the case, then what you are seeing is just client-side scaling in your browser. And there shouldn't be any cropping. The image is full resolution, but just being scaled to 100% of the container width. That doesn't mean the image is actually that size. That just means that it's presenting it to you in a manner so that you can see the full contents of it. When inserting into your rich text field, do so by clicking the image button in the toolbar, rather than by dragging the image into there. The act of dragging may cause your browser to insert its own width/height tags as part of the clipboard data.

This is good to hear. While I've not used Laravel, I honestly thought it was a completely different animal in terms of a framework. That being that ProcessWire is a content management framework/system and Laravel is an application framework. But to hear that there is enough crossover that you can accomplish similar things sounds good. Perhaps we should put more focus towards appealing to framework users. I agree with you that once we have Composer support, that will open up a lot of new possibilities.

Try posting this to the ModulesManager thread so that Soma sees it. But I ran into a similar issue at one point after migrating a site. You may have to go back and check that your /site/assets/cache/ is writable, and perhaps manually remove an existing cache file if it exists.

If you want to use the LanguageSupportPageNames module, I think it's better to go ahead and use the dev branch (if you are in a site development phase), just because (like Soma mentioned) the development for it is a lot further along there.

Some fun stuff just pushed to the dev branch: the core now includes a Modules Manager "Lite". The screenshots below best describe how it works. But it lets you install modules from the directory just by typing (or pasting) in the module's class name. It also provides a 1-click capability to check for a given module's updates and upgrade it when necessary. Beyond that, the modules screen is now split into tabs: Site, Core and New. Site shows just your /site/modules/, and Core shows just your /wire/modules/. The New tab is where you can install modules. I really wanted a solution that kept the actual browsing for modules out of the CMS. Not because I think it's a bad idea (it's a great idea) but because I wanted the modules directory (modules.processwire.com) to serve that purpose as much as possible, at least as a default. That way I don't have to worry about scalability as the size of the modules directory increases. Plus less automation might make the newbies be a little more careful about what they are installing and where it's coming from. The power of the automation in ModulesManager here is so powerful it scares me, so think it's better for the users that know what they are doing. Lastly, ModulesManager is one of the best modules out there and Soma does an amazing job with it. Bringing a little taste of ModulesManager into the core I thought would help both projects. Most credit for the new core "Modules Manager Lite" goes to Soma (though he doesn't yet know that). It's all built around his code lifted directly from Modules Manager. Hope that's okay Soma? Your code now powers not just the new stuff in ProcessModule, but also the new WireHttp::download function, and the new wireUnzipFile() function, all added this week. People who want the most power will still want to use Soma's Modules Manager. That does a whole lot more than the built-in one does, including installation of themes, checking for updates en-masse, and browsing and filtering through the modules directory. But now you can install ModulesManager or other modules without having to manually FTP things to your server (so long as your /site/modules/ is writable). Please let me know if you guys run into any issues with it.

Okay just tested with AdminBar, and man it is nice to see it again. Everything works for me. I think I'm going to keep it here. You might want to check your site to see if you've got any JS errors or anything like that. If I understand how AdminBar works correctly, it could be interrupted if you had something else on your page triggering a JS error, or didn't have jQuery or something (possibly jQuery version?)

AdminBar is great I agree. But I'm so set in my old ways that I still always just place my own edit button in the top left corner, and nothing else. So I haven't yet had the opportunity to test AdminBar with 2.3.1. I'll install AdminBar and see if I can figure out what the issue might be.

Actually autocomplete fields have never worked in tabs before... they always had to be on the primary/first tab in order to work. But a week or so ago, someone submitted an update that lets them work in tabs, so I went ahead and committed it to dev. It works here at least. If you are running the latest dev, you might just want to check that you don't have an old JS file cached or something (hit reload a couple times on the page). Here is the commit where it was added: https://github.com/ryancramerdesign/ProcessWire/commit/9a3bf9caa47f204e938213c8ff5cd31691a7c245 If the issue persists, please let me know what browser.

This is a little bit of a tough one because dates are basically sortable integers. So a 0 is considered end of 1969 (or somewhere around there). You can query for those with a 0 date value and those with a date>$now with separate children() calls. But when it comes to pagination, the question becomes how you would want to sort those with no date value and those with a date value. If one or the other can be consistent at the front or back, that will make pagination simpler. Also you can manually set the pagination limits on a PageArray with $all->setLimit(); $all->setTotal(); etc. Another option is that you could always query the database manually to find the IDs of the matching pages, then bundle that into your children() query. Here's two example, one using PDO (PW 2.3.1 and newer) and one using mysql (PW 2.3.0 and earlier): // using PDO $now = date('Y-m-d H:i:s'); $sql = 'SELECT pages_id FROM field_expiration_date WHERE (data IS NULL OR data=0 OR data>:now)'; $query = $database->prepare($sql); $query->bindValue(':now', $now); $query->execute(); $ids = $query->fetchAll(PDO::FETCH_COLUMN, 0); $expired = $page->children("limit=20, date<=$now, id=" . implode('|', $ids)); // using mysqli $now = date('Y-m-d H:i:s'); $sql = "SELECT pages_id FROM field_expiration_date WHERE (data IS NULL OR data=0 OR data>'$now')"; $result = $db->query($sql); $ids = array(); while($row = $result->fetch_row()) $ids[] = list($row); $expired = $page->children("limit=20, date<=$now, id=" . implode('|', $ids));

I'm not sure we can answer this without seeing the bigger picture here. But since your code is iterating through a property of $page, and not referencing other variables you had like $child or $result, chances are you can put this wherever you want. It looks to me like it should be outside of any other loops. I would just put it where you need it.

Technically repeaters can be nested (I've done it before, though disabled it), but it creates so much potential for problems that I didn't think we'd want to support that. Plus considerations for 3rd party Inputfield modules, and the list goes on. The situations where nested repeaters are worth the compromises is pretty rare, as there's usually a better way to accomplish the same thing. Ultimately decided we shouldn't have support for it at this time. But if you can describe what you are trying to accomplish with nested repeaters, I may be able to describe alternative ways to achieve the same thing.

Great form builder implementation you've got here too. I love the way you styled it and the way you've setup JS-based field dependencies. Awesome work.

Shopify is another decent payment solution to integrate with ProcessWire. Shopify is pretty much self running and easy to setup (they host it), but has a feature called post order hooks that you can have ping your defined URLs (in your PW installation) with JSON data about a completed order, etc. This makes it fairly simple to create or modify user accounts or other pages based on the results of a store transaction.

I don't see anything wrong with #2, other than that I'm wondering if your $pages->get($local_lang_url); really makes more sense to be a $page->rootParent call instead? But if your current one isn't working, I would suggest that the /de/ page does not have any visible or viewable children that have a field 'page_key' with the value 'block_m-help-legal'. Are you sure you didn't intend for your children() to instead be a find()? Example: $blocks = $page->rootParent->find("page_key=block_m-help-legal"); The problem with #3 is that it looks like you are expecting a PageArray, but getting a Page. If you simply changed your get() to a find(), I believe it would do what you are expecting. And it should return the same exact results as the example above I posted. If you can achieve the same thing with one find() that you could with a combined get() and find(), then the single find() will likely be faster. For all practical purposes, it probably doesn't matter much though. If your level-1 pages are language segments, like "/de/" as you mentioned, then $page->rootParent will always refer to the root of your current language. I have a feeling this is what you want to be using rather than detecting it some other way. find() is not slow. Every function that returns a Page or PageArray eventually gets routed through find(), so we've really tried to make sure it is fast and optimized. But I still think you probably want a $page->rootParent->find("page_key=..."); rather than a $pages->find("has_parent=...");

Thanks for the update–It works perfectly here! I will submit a pull request to you that makes the title attribute translatable. I also moved the hook-attach logic to a ready() method (rather than init), and made it attach the hooks only if the page template is 'admin'.

I totally agree that we should strive to keep clients away from code when we can. But things like phone numbers and email addresses aren't far off from the type of codes we're talking about here. Sometimes a bit of code (more a tag in this case) that references something is the simplest possible solution from a development standpoint. In this particular case, the tag could technically be completely behind the scenes and the client could just see an image. That would be ideal, and I think this is what we should strive for long term. But the implementation of that is no doubt expensive (time and money) and has editor dependencies. The solution that works for TinyMCE 3 won't work in CKEditor or even TinyMCE 4. I don't think anyone disagrees on what would be the perfect solution from the user standpoint, and this is what we should eventually aim for… when someone can afford the time/cost investment to make it happen. But I also like to see solutions that solve problems, that are maintainable and realistic with time and budget. They provide solutions to questions that would otherwise remain unsolved, sooner rather than later. Very often these are also important intermediate steps that eventually facilitate creation of something even better.

Currently I can't see any reason why this wouldn't work. But a few things you might try: 1. Clear your opcode (APC?) cache. I do this whenever I encounter something odd that doesn't add up. 2. Clear your modules cache. You can do this by clicking "check for new modules" on the Modules tab. 3. Check your Comments field settings. Is it set to redirect after post? Try disabling that option, temporarily, to see if it makes any difference. 4. While I'm not aware of any issues related to this in PW 2.3.0, maybe try switching to the dev branch (2.3.1) just to change things up. Also: Uninstall your module. Then click "check for new modules", then re-install it. I'm wondering if it maybe started out as NOT autoload, and that setting got cached in the DB. PW doesn't load all the module settings at runtime, as it caches some of them, especially autoload status.

Wow that was quick – Thanks, great update! It seems to work well, but two issues I'm running into, at least on the default admin theme: Clicking the toggle button for the first time works, but throws a JS error. Clicking it a second time does not work. So you can switch to expanded view, but not switch back to tabs. The JS error is: "Uncaught Error: cannot call methods on tabs prior to initialization; attempted to call method 'destroy'." I did try to debug it a bit, but wasn't sure how to fix it. Not a bug per se, but the position of the toggle icon seems a little unusual at least in the default profile (see screenshot). Maybe there is something that works better across themes, not sure? Though let me know if you think there is an issue in the default admin theme CSS that needs tweaking. Thanks for your great work on this module. It's already one of my favorites.

WireArray implements PHP's ArrayAccess interface, so actually the something like $images[0] ideally would work. The reason for the inconsistent behavior is that images are indexed by filename, not by number. So $images['filename.jpg'] would be the actual ArrayAccess implementation. However, I think I could find a way to make it work by re-implementing the offsetGet() method in the Pagefiles and having it do a slice() to return a specific index. Thanks for reporting it!

Given that this piece is informational only, and not tied to any user input, hiding it with CSS or JS seems adequate. This one may be tricky to target with CSS since it doesn't have a defined id attribute. But I think you could do it with: #ProcessPageEditSettings .InputfieldMarkup:first-child { display: none; } You can put this in your own css file in /site/templates/styles/admin.css. Then edit your /site/templates/admin.php and put this at the top (after the opening php tag): $config->styles->add($config->urls->templates . 'styles/admin.css');

I'm really liking this module. Thanks for making this! I used it yesterday, all day on a multi-language site that I'm developing with 5 different languages. It has really made the interface a lot nicer to look at and use. It makes me think we should have this in the core. There are two things I think I'd personally add to it though: I'd make the tabs that have un-populated text a little different, perhaps a little faded or lighter text or something to indicate the empty state. Either that, or the populated tabs bold. I'd add an option to to switch between tabbed view and regular stacked view. The reason is that I anticipate clients have cases where they are translating and want to see the text in multiple languages at the same time. But overall tabbed view seems like a much better default than what we've got now. Has anyone tried this with Teppo's text version control module? I'm wondering if it would break that... will probably find out later today.

There are a few different ways to approach a multi-language website. The answer will depend on what multi-language solution are you using. If you are using the multi-language page names module native to PW 2.3, then you would have checkboxes on your settings tab that indicate whether the language is active or not. However, since you mentioned you have 2 different pages, I'm guessing you are using some other multi-language solution, but not sure which?

Just to confirm, the issue is, or is not, occurring in the latest dev version?

I would still like to resurrect it in PW2, but just haven't yet had the need for it in one of my projects. There are also some alternatives now we may want to look at too. But I would like to see a MarkItUp option in PW.