ryan

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.

Chances are the text you've got is already entity encoded (like from TinyMCE), and the HTML5 validator is complaining about an ampersand somewhere outside of that. Can you 1) remove the entity encoding textformatter for that field; and 2) post the URL (or PM to Teppo and me if you prefer) so that we can see the full context?

Not sure you'll get a good reply on that just because I'm not aware of anyone else here using the Yii framework. However, if you think of your ProcessWire template files as regular PHP files (which is essentially what they are) you can easily include any other things that you want. I would start there and simply include() your Yii framework file in your template file and see how that works.

Thanks for finding it. Looks like a bug, but an easy fix that will be committed later today. I missed it because I'd changed my default search operator to %=, which doesn't exhibit the issue. What is the silver admin bar? Is this the AdminBar module or something different?

You need an Avatar one of these days Kongondo! If I recall, WillyC made you a pretty awesome one awhile back. Though if you like the anonymous man one, maybe we can at least dress it up a bit (perhaps a hat, ears, gratuitous lens flares or something?)

Don't forget that PW pages can act as a media manager. When it comes to inserting images into copy (like from TinyMCE) you can choose images from any other pages (see screenshot). Taken to the next logical step, you can choose to create a section of pages as a media library, should it suit your purpose. While there are some aspects of a media manager that may be beneficial, I've found the need for it to be null once you really get into the PW way of doing things… even on sites built completely around photos. If we were to add a media manager of some sort in the future, it would be primarily because people are likely to find and understand it more easily, not because it would be doing something you can't already do in PW.

Michael, it sounds to me like you want to use a web service to display a calendar. Is that correct? Or are you wanting to import the calendar to your site into pages? Since your goal is to display a table with the 5 next events, I think the best bet is to use an approach similar to the MarkupRSS or MarkupTwitterFeed module, which is to poll the web service, display the results, and optionally cache them for a period of time. I've not worked with caldav or baikal, so don't know the considerations there but most likely the approach you take would be the same in ProcessWire as it would be outside of it. Meaning, any PHP examples you find from the company providing the service should be applicable in ProcessWire.

Did you get any errors during installation? The 500 error you are getting there indicates Apache is most likely upset with something in the .htaccess file. But to double check, rename your .htaccess file to htaccess.txt (temporarily) to see if the 500 error goes away (I'm guessing it will). If it does, rename it back to .htaccess and then start commenting stuff out in the .htaccess file till you can determine what it is, starting at the top and working your way down. Focus on the parts that aren't surrounded by <SomeBlock>...</SomeBlock> sections first. Please let us know what you find. Chances are your web host has disabled some feature typically allowed in an .htaccess, and we just have to determine what it is and find an alternate. If it does not, please PM me a link to a PHP file on your server with <?php phpinfo(); in it.

Great site Nico. I'm assuming so that the images look sharp on high DPI displays (aka Retina displays). We do the same thing on processwire.com with several images where it counts, doubling the resolution and scaling down. Though not more than double. So a 960px to 240px would be more than necessary for any displays that I'm aware of.

I've not ever seen that particular issue. Though know that there was a sorting bug in a certain MySQL version (bug in MySQL not PW), so that would be something to look at. That's the only thing I can think of. Unrelated, but also be sure to get your PHP version up above 5.3 if possible.