ryan
-
Posts
17,254 -
Joined
-
Days Won
1,708
Everything posted by ryan
-
Nice work! Thanks for posting. Very good use of videos and quality production throughout. What do these conditional comments mean at the top? <!--[if IE 9 ]> <html lang="en" class="no-js ie9"> <![endif]--> I hadn't seen the "no-js ie9" before (and all the others for IE), so was curious about that.
-
Finally got a moment here to install and test it out. What can I say, it's awesome. Love it! This is how I'll be uploading files from now on. I'm thinking this must go in the first version of 2.1. One question is if there needs to be a 'drop area'? Is it possible to just have the entire field be a drop area? -
If you want your custom 'date' field to be one that can be sorted on, check the box for 'autojoin' in the field's advanced settings. That's the only technical requirement to make a page sortable by that field. Following that, you should be able to select it in your page's children tab as the default sort. Multiple sort parameters in your selector are just fine, and ProcessWire supports this as long as those fields are 'autojoin'. It also sounds like you may need to add a time component to your 'date' custom field, so that you can sort by two entries in the same day. PW supports this, but you have to include time codes in your date input format, i.e. "dd-mm-yy H:i" where "H:i" is the time component (hours and minutes). (If you need them, here are the full set of date and time codes used by PW: http://www.php.net/manual/en/function.date.php).
-
Thanks Doolak, that's very kind of you. That makes my day when I hear someone likes ProcessWire so much. I will do my best to make sure it keeps getting better and better.
-
ProcessWire doesn't attempt to do any pagination with a "limit=1", so at present, you need at least a "limit=2" in order to paginate. For the 1969 date, that's the first value a date can have in a unix timestamp, so it basically means there is no date set. I'm guessing that the "default to today's date" was added sometime after the pages with 1969 were created. Either that, or that the field was added to a template but a date wasn't set in all the pages. The default is only set when you edit a page, so you would have to edit and save a page for it to pull in that default if it didn't have it before. In your case, what you may want to do is skip over the fields that don't have a date set: if(!strpos($page->date, '1969')) { // output your date } I'm trying to think of ways to avoid this problem from the core. Perhaps I should have PW return blank, rather than a formatted date, when the timestamp value is 0.
-
Just watched the screencast and it's great! Now I understand what all the excitement is about. I haven't yet installed it–only a few minutes left before I have to go, but planning to install first thing tomorrow morning (or later this evening, if possible). Love the way you did the progress bars. This all seems like quite a fantastic UI option for uploading images or files. Well done!
-
Add rel="nofollow" when adding a TinyMCE link
ryan replied to formmailer's topic in Wishlist & Roadmap
I agree that this is probably too specific for the core. But you can achieve this pretty easily and automatically just by doing a str_replace before outputting the field. So I recommend adding something like this (below) somewhere in your template before that field is output. This will automatically add a rel='nofollow' attribute to any external links: <?php $page->body = str_replace(' href="http://', ' rel="nofollow" href="http://', $page->body); -
Any time you get "Unable to complete this request because of an error", you can get more details about the error by either enabling debug mode (in site/config.php) or looking in your log file at /site/assets/logs/errors.txt. I don't see any reason why it should be erroring out, so am curious to find out more. But I did notice that one one example you referred to a "news" template and another the "news_article" template... are these two separate templates?
-
Pete, thanks for continuing to try and debug this. Admittedly, I'm at a loss so far–it seems pretty bizarre that it's not working. Though it's also the end of the day here and my mind is mush. I almost wonder if there is some issue in the version of PHP you are running (perhaps combined with Windows), or if there is some PHP setting that's interfering with our file operations. Can you take a look at your phpinfo() and see what PHP version you've got? Then we can look in the changelog and see if there was some version-specific issue. While you are there, check to make sure you don't have any safe_mode or open_basedir restrictions in effect too, just in case.
-
Pagination won't appear if there aren't enough pages to paginate. So the first thing to check would be that you've retrieved a group of pages (with "limit=10" or some other limit, in the selector), and that the total number of possible pages is larger than your limit. PW won't bother with pagination otherwise, since there would be no reason to have it. If this doesn't resolve it, please post a code example or attach your entire template file if possible.
-
Looking at your error message, I see where it came from. There was an error in my earlier example (sorry). At the end of it, it should be: // output the pagination navigation echo $a->renderPager(); rather than $images->renderPager();
-
Sounds good, I've added this to the latest commit so that "đ" should now convert to "dj".
-
Pete, thanks for your assistance in figuring this out. It might be useful to get a debug backtrace from the point where that error is occurring. If you want, try adding this at the end of the getImageInfo() function in /wire/core/Pageimage.php (before the last line, return statement): if($info === false) throw new WireException('for backtrace'); You'll also need $config->debug (debug mode) to be on. If you can paste in the backtrace here, I might be able to get a better sense of exactly where it's running into trouble. Also, we were originally talking about this having something to do with portrait vs. landscape orientation of the photo. I'm guessing that's no longer the case, but just wanted to double check?
-
Module: Languages (multi language content management)
ryan replied to Oliver's topic in Modules/Plugins
The "noMove" option means that the page can't have it's parent changed. But it may still be sortable with it's siblings. The PageList uses the "move" label in a more general sense to refer to either changing the parent, sorting, or both (just depending on where you happen to drag the page to). As a result, a "move" link may still appear in the page list even if a page's template has the "noMove" option set. In this case, the "move" link is only referring to sorting within the same parent. If you drag the page to another parent, PW should tell you "no". Though, after getting the alert box, it might still look like it moved in the PageList, but that's only because I haven't figured out how to reverse it from the javascript (yet). The page didn't actually move. Hit reload or click "pages" and it'll be back where it was. Though let me know if you find it's not working this way. -
Thanks I'm correcting the case issue. As for the "@" in front of the chmod, that just suppresses warning messages, so not sure it would matter here. Using it is just an old habit that pops up every once in awhile, though I generally prefer not to. Then again, I don't use Windows – does it account for something different in Windows? I'll adjust the function name case now. Not sure why I've got UCWords case on those! oops. Can you confirm that this error definitely appears to have something to do with the image size or resolution? Do you run into any issues on smaller images? If not, do you know about where the cutoff is?
-
It's funny you should mention that because I just added ability for InputfieldPageTitle.js to convert single to multi-char about an hour ago. So we should be able to make it convert "đ" to "dj". Do you know if this is a fairly universal conversion? I'm not sure if this character appears in any other languages where it might be converted differently?
-
I didn't write the module (other than adding a few edits), so can't say for certain, but I'm thinking this might work: <?php $page->setOutputFormatting(false); if($page->map) { // display the map $page->setOutputFormatting(true); echo $page->map; } else { // no map to display. $page->setOutputFormatting(true); } If that doesn't work, you may want to just modify the module itself. I would try editing the formatValue() function and adding this at the top: if(!$value) return ''; Lastly, another option is that you could edit map field's config settings and turn off the auto-generated map markup. Then generate your own (like in the earlier examples in this thread).
-
I'm thinking it should just go through the same exact validation as all the other uploaded files, if possible. This validation mainly consists of making sure it's the right file type (via extension) and renaming the file to be consistent with the characters PW allows for filenames. Though it also does some other stuff, like optionally unzipping zip files. The image Fieldtype also resizes the original image file if necessary (as you know). But don't worry too much about this stuff now– If you get a working example going, I'll be happy to place all the code where it needs to go. And of course, take your time… no rush. I just wanted to make sure I get you everything you need and all questions answered when you need it.
-
Wow, 1000 posts didn't realize that. Thanks!
-
Change this: foreach($rootPage->children as $child) { to this: foreach($children as $child) { The reason why that's necessary is because every time you call Page::children it's returning a new PageArray. So you need to specifically use the one that you ran the prepend($rootPage) on.
-
PW actually won't attempt pagination with limit=1. It needs at least limit=2 before it'll attempt to determine totals needed for pagination. This is an optimization that lets the system run more quickly, since so many parts in PW use limit=1 (and this is the first instance where a limit=1 need has turned up in pagination). The more I think about it, I have to imagine that pagination wasn't working before because page numbers must have been turned off in the template. That's the only reason I can think of why our previous examples may have not worked on his site. One option for single-page pagination is to just use next/prev buttons. $page->next() and $page->prev() return the next and previous sibling pages, making this type of pagination very easy. i.e. <?php $prev = $page->prev(); $next = $page->next(); if($prev->id) echo "<a href='{$prev->url}'>Previous Page</a> "; if($next->id) echo "<a href='{$next->url}'>Next Page</a> "; You wouldn't want to do this with something that has thousands of pages, but it would be a good solution for smaller pagination groups.
-
I haven't tried it, but I think it would probably work if you added this right above the foreach(): $children = $rootPage->children; if($rootPage->id == 1) $children->prepend($rootPage); Then your foreach would be changed to this: foreach($children as $child) { You'll also need to add something to prevent it from going recursive on the homepage, otherwise you'll get a double menu. So I think you could take this approach -- anywhere that says $page->numChildren or $child->numChildren, change it to $page->numChildren && $child->id > 1, like this: if($child->numChildren && $child->id > 1 && $parents->has($child)) { and if($page->numChildren && $page->id > 1) $s = str_replace(...); Let me know if this works...
-
Glad that you got this working. Though admittedly, I still have no idea exactly what's happening on the front end or what it looks like. All I know is that it sounds good. The ProcessPageEdit doesn't actually have any logic for saving custom fields, all that is delegated to the Inputfield modules. For instance, InputfieldFile. That module creates an instance of WireUpload (/wire/core/Upload.php) to retrieve the file and make sure all is good with the filename, file type, etc. I'm thinking that's probably where the logic should go (WireUpload class), because then it'll be available to all file upload fields. The destination path for a given page's files can be found from the field it's going to, i.e. $page->your_files_field->path; You can also get it without knowing the fieldname like this: $page->filesManager->path;
-
You mentioned that pagination wasn't working–can you provide more detail about what it is doing? Also, double check that page numbers are supported in your template settings, under the "URLs" tab. Without that turned on, pagination will not work.
-
I'm not sure what needs to be done to support the multipart/form-data on PW module side? PW's forms are multipart/form-data already, but I think you are referring to something else. I don't know how the HTML5 upload script works exactly. But if there is anything I can add, just let me know and I'll do it.
