Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/25/2012 in all areas

  1. This is something that a lot of us do because it's fun, not because it's something that we have to do. We might make a module so that we can do something like this because it's fun, satisfying, and efficient (plus it looks good) … echo $pages->find('brand=/brands/audi/, mpg>25')->renderCars(); But the reality is that it's also not necessary. You could perhaps more easily just package it into your include file and do this: $cars = $pages->find('brand=/brands/audi/, mpg>25'); include("./render-cars.inc'); And in your render-cars.inc: <?php foreach($cars as $car) { echo "<p>{$car->title}: {$car->mpg} mpg</p>"; } What I'm trying to get across is that much of the things we all create and use modules for is optimization and fun. Perhaps others feel differently, but in my case, most of my sites don't even use any modules other than what comes with PW. I create modules when I want something I can re-use on multiple sites or share more easily with the PW community. Another point about modules is that they are a whole lot simpler than you would ever imagine, once you get going with it. But the lack of ability to create modules is not going to limit your ability to use ProcessWire in any way. You can make it do pretty much anything without having to even know about modules. But when the time comes that you become interested in it, it will only increase your enjoyment of development. So when you see what appears to be complex development conversations about modules and such, don't worry. What you don't know isn't going to hold you back in ProcessWire. It already seems like you have a really good understanding of development and using ProcessWire. Based on your past posts, I feel confident you can push ProcessWire to do what you need when you want to. And we're always here to help with questions and problem solving. If I were you, I would keep using ProcessWire for everything that you are comfortable using it for. When situations come up that you feel can't be as easily solved with ProcessWire, then investigate services like what Pete mentioned (Lemonstand, Shopify, Google, Facebook, Flickr). There are services out there for nearly everything and this is where a lot of functionality is trending. For instance, look at the quality of a comments service like Disqus... it makes you wonder if we aren't far off from the time when built-in comments are no longer considered a required core feature of CMSs. When we had to setup a forum for ProcessWire, I never considered trying to create it myself in PW. Instead, we went with SMF, and then IP.Board. Services like these and others are better than what you can reasonably expect to build on your own, or what you could expect to come with (or be added-on to) any other CMS. Honestly, if you use ProcessWire and then utilize services for the things you don't want to build, then you will be able to do everything you could ever want. And more quickly, more securely and easier to support, than if you were trying to leave it all to a CMS. For the rare cases where you need something that won't be easy to do in PW, and your service options are limited, then bring WordPress into the mix. Not that WordPress can do much on it's own, but it's following is so much bigger than anything else that literally every possible thing has been coded for it. I certainly wouldn't want to use WordPress as my CMS, but I have no qualms about pulling it in when something that I need is available as a WordPress plugin. You aren't going to find any other CMS that has as much 3rd party stuff built for it. WordPress is easy-enough to figure out in a day (from a development perspective) that you also won't find yourself as frustrated as in Drupal (at least, this was my experience). It's not much prettier than Drupal from an output generation perspective, but it will be much more respectful of your time.
    3 points
  2. Hi, These two sites have existed for quite a while but they've recently been converted to ProcessWire from Textpattern and ExpressionEngine respectively. http://tracktime-asia.com/ - it also got a slight design upgrade in the process. I couldn't help myself. http://arwa.org.au/ Regards Marty
    1 point
  3. Here's the new blog profile that's built up from the Skeleton CSS framework: http://processwire.com/blogtest/ As Skeleton doesn't come with any real design elements, it's much more of a blank slate than Foundation. So I put a little design time into this one and the profile is much more custom than the Foundation one. I think it looks a lot better than before. Of course, it could use some color and perhaps icons and imagery, but thought it might be a much better starting point than before. I'm thinking we'll make colors configurable via Soma's color picker Fieldtype/Inputfield. I've also added a 1200px view (something that Skeleton doesn't come with) so that this profile has a nice "wide" view, in addition to a normal desktop, tablet and mobile view. Beyond a change from Foundation to Skeleton, this one also includes a lot of improvements and tweaks to the profile itself. Since this is still a work in progress, I won't post an updated ZIP yet, but just wanted to post this preview to the latest version.
    1 point
  4. You can do it like this to set it to today's date/time: $page->date = time(); Or like this to set a specific date/time, you can use any format that PHP's strtotime() function accepts, like this: $page->date = "2012-06-25 11:36:00";
    1 point
  5. I think more likely we're both inspired by jQuery. However, it is possible they took inspiration from PW on their API. I published the very basics of the ProcessWire API in 2008 here. Then I emailed it to a few CMS authors, hoping someone would take interest. This was at a time when I wasn't yet sure if I wanted to pursue making ProcessWire 2.0, or joining another project. So I tried to put some stuff out there to see if anyone took interest. I got no interest from other CMS authors (at least not that I knew of), but got a lot of interest from other web developers (users of CMSs). So that's one reason why PW 2.0 open source went forward.
    1 point
  6. Thanks guys for your reasonable suggestions. It seems no one has a solution out of the box for this, so i'll have to try it myself. I think I will use a combination of apeisas idea with child pages, incorporating with bens suggestion of using PHP When for generating tbe child pages. I will post the results here when I'm finished.
    1 point
  7. That's why I'm suggesting namespaces for version 3 - clearly there is no way changing all the class-names to using namespaces is going to be backwards compatible. Though on the other hand, I don't suppose it's unthinkable you could actually write out the class-name mappings from my tool, and derive an upgrade-tool that would rewrite third-party extensions and applications the same way it rewrites PW... I personally would worry less about upgrade paths - in my 14 years of experience, upgrading an existing application to a new major release of a framework is very, very rare. For the most part, it just doesn't happen - and major revisions should not sacrifice major improvements to support 5% of the applications that upgraded; most likely 95% of applications will be new applications...
    1 point
  8. I was thinking this at one point, but the project was cancelled so I didn't get into implementation part. It had the special need, that the recurring event need to be it's own entity (it might be same event, but different time - but also it might be in different place, have different price etc). How I started to approach the problem was to have "events-item" template which could have children with template "events-instance". Events instances would inherit most of the data from their parent event, but could override some parts of it. And how I would have implemented is that when saving the "event-item" you could make some selections "Repeat once a week, until <date>" and that would create the required amount of instances as children. Pretty simple actually that way.
    1 point
  9. Yes and no, interrobang You're right, and I just solved it using your solution... But you seem to have stumbled into a protected field, maybe? Using "sortfield" as a temporary field throws an error, renaming it to something like "mysortfield" makes it work like a charm! EDIT: so sortfield it's the sort setting for a page's children.
    1 point
×
×
  • Create New...