Jump to content

ryan

Administrators
  • Posts

    17,240
  • Joined

  • Days Won

    1,704

Everything posted by ryan

  1. Much of this defers to the GNU v2 license. My thoughts are that people should feel free to make their own admin theme and put their logo (or their clients logo) wherever they see fit. But regardless of admin theme, I do think the software name ProcessWire, version number and copyright should always remain in the footer of the admin at least. The reason for this is that I don't ever want ProcessWire to be a burden on a client. Web sites very often outlive the relationship of the site developer to the client. I think it's important for the client to know what software and version they are using and where it came from. Without that, if some future issue surfaces, the client would be blind and ProcessWire would be a burden on them. Can you imagine white label installations of any other major open source CMS out in wild, and what a security nightmare that would be? Keeping this information in a place where the client can find it keeps everyone honest about how the software is licensed. If someone just provided a re-branded PW to a client and charged them $25k for it, I think it's important that the client knows they are paying for a service from their developer and not the software. If a company still felt strongly that they needed to remove the software name, version and copyright from the admin, then I'd want them to keep and maintain a long term support contract with us and make the GNU license really clear to the users of the software.
  2. Awesome update! I just dragged in 6 files... beautiful! Even better now that I can just drag them anywhere in the field. Thank you for your fantastic work with this. I'm going to dig deeper into your code here soon so that I can figure out how to get this to be built-in to the WireUpload class.
  3. Great job Pete! Very cool to see this integration, and looks like you've really done it nicely. Thanks also for posting this screencast, it was great to see this in action. As a side note, I noticed that there were no margins between the individual fields in ProcessPageEdit (in your screencast). Just wanted to check if you had changed something in PW's stylesheet to do this, or if that's the way it displays for you? If so, it's a bug, and I'd like to find out what version of Firefox? Thanks, Ryan
  4. Thanks for finding it. It's a bug. Just fixed in the latest commit.
  5. Very cool. Seems like a handy thing! Though also a little sad that we have to do this for IE. But that's life, and this seems like a good way to deal with it. Is there any advantage to doing this with the <html> tag as opposed to the <body> tag?
  6. Thanks for your thorough investigation into this issue. I agree it is a strange one. If you find some way we can bypass it, I'll be glad to update PW's code. Though I don't currently have a way of testing this issue (running on different platforms). This would be tricky because the process that handles uploads is completely different from the process that handles image manipulations. ProcessWire expects a file to be part of it's file system before it starts manipulating it. So while I'm sure it's possible, it's not a straightforward thing because it would be an architectural change. I'm wary of architectural changes to support an obscure bug in Windows. Here's something I found in the user comments on the unlink documentation page at PHP.net that has me wondering: Doesn't exactly sound like a cross-platform compatible solution, but maybe a hack to make it work in Windows. If you find something like this works, let me know and we can always make it perform this action if it detects it's in Windows (or perhaps with a config option).
  7. Pete, take a look at /wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js in the latest commit. Yesterday I added the ability for it to do single-to-multi char replacements, specific to some German characters that Soma (issue #41) found weren't translating correctly. But the same approach could be used to convert '&' to '-and-', just by adding it to the 'srch' and 'repl' arrays in there. I would go ahead and add the '-and-' in there if I could assume the language was English, so I think you are right that we may eventually need a multi-language support solution for this.
  8. For a system that doesn't yet have multi-language support, this sounds fairly custom to me. But my experience with multi language sites is so far limited to just talking about it in this forum. I'm not sure that I understand 100% what you mean, though I do get part of it. I'd always like to keep PW as simple and open-ended as possible. I'm wary of forcing people into one approach or another, or dedicating all resources to a specific approach. We need some multi-language support in fields themselves specifically for the admin-side of things. But this isn't necessarily ideal on the front end where a multi-tree approach is more of a best practice (especially when it comes to search engine indexing, bookmarking, linking, etc.). So my hope is to ensure that the system if flexible enough to adapt and let the developer determine the best approach for their site. I'm excited about what LorGG is developing as it sounds like it streamlines the multi-tree approach.
  9. I agree that the #3 option makes sense. Though thinking we might change the word "parent" to "parents", so that it clears all the way up the tree to the homepage. This seems simple enough. Pete those are great ideas about locating all the pages with references to the current and clearing those as well. Though I'm afraid to go there because the only way to really guarantee that a site is up-to-date is to expire the entire cache. We can track some things (like page references) but not others. So I worry about the ambiguity of any cache clearing options that involve an unknown set of pages ahead of time. Doing so may make some people think that PW may be smart enough to figure out everything that needs to be cleared. If there is one thing that causes confusion among clients, it's always caching, in my experience.… Client says: I respond "go save the homepage, or just wait an hour, it's on a cache". I've dealt with so many of these support calls in the past, that I tend to use the cache sparingly. A possible 4th option would be one that Antti mentioned earlier, which would be to provide an InputfieldPageListSelectMultiple that lets you specifically select all the pages that should be cleared. While I'd rather make it "clear pages using these templates", the truth is that clearing specific pages (rather than pages using specific templates) is quite a bit simpler to implement in the current system. Though I'm going to toy around with the current cache system sometime to see if there might be a way I can get that per-template cache clearing. Caching is always a compromise… my opinion is that most people should start with no caching, and only turn it on when they find they need it. And if they find they need it, they should take a close look at the MarkupCache too. But I'll work to expand the caching options, as I think these open a lot of doors to PW's use in high traffic sites.
  10. Definitely major marketing value in this. This is one of those things that will be great to show in the PW 2.1 "what's new" video.
  11. The plan is to add an "advanced" section (default collapsed) in the TinyMCE link editor where you can specify things like class name, title, target and rel. I put it on my to-do list a little while ago because I've had several occasions where I needed to add a class attribute to a link, and don't like having to go in and do it in the HTML view (and don't like telling the client to do that). I figured if I added that, then it makes sense to provide options for other <a> tag attributes, so rel will definitely be one of them. This isn't officially on the roadmap because it's a small update that won't take more than a couple hours, and will get put in whenever there is time. So now that I know there are others with a similar need, it'll likely come sooner rather than later.
  12. 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.
  13. 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?
  14. 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).
  15. 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.
  16. 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.
  17. 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!
  18. 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);
  19. 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?
  20. 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.
  21. 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.
  22. 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();
  23. Sounds good, I've added this to the latest commit so that "đ" should now convert to "dj".
  24. 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?
  25. 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.
×
×
  • Create New...