Jump to content

Leaderboard

Popular Content

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

  1. It would be nice to be able to turn upscaling off (set it to false on ImageSizer) via size() function of Pageimage. Currently size accepts two parameters (width, height) -- how 'bout adding upscaling (true/false, default to true.. or perhaps "disable upscaling" and default to false, whichever makes more sense) as third parameter?
    2 points
  2. Hey Ya'll, Just for fun, I'm going to do a Security Analysis on Processwire by following the principles in Hacking Exposed 3 - Web Applications. I think It'll be nice to show my clients a final summary to help reassure them how secure things are, while giving me some credibility for being security conscious~ Anyways, I'm kind of busy these days, so it won't be updated too often, and of course I'll let The PW team fix any issues prior to releasing any security holes. BUT, if your interested, the feel free to subscribe to the RSS feed for this topic.. otherwise you can find it here: http://neilpahl.com/logs/security-projects-public/processwire-cms-security-analysis/ if there is any interest, I'll make an email subscription available for this topic feed~ Let me know if there is any specific area you feel the security should be looked at more closely... Cheers,
    2 points
  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.
    2 points
  4. Here are a few ProcessWire sites I've launched in the last month or so. Nothing real big or exciting here, but figured it's good to post new stuff here when available. Blue Ridge Beverage This is a beer distributor for the state of Virginia in USA. I designed it back in 2009, but the client only recently came back and wanted it developed and launched. A friend did most of the development and did a great job getting everything working in ProcessWire. The client is still populating content here, so there are a few holes, especially in the Beverages database. Almanac of Architecture & Design Before you click on this one, note that this is using the default ProcessWire "basic site" profile (the client fell in love with it and didn't want to change… what can I do). But don't let that fool you, because this is actually quite a large and comprehensive site, particularly the Architecture Firms database. This one has dynamic maps, graphs, search engines and stats galore. There's also some fun stuff in the Buildings section. This site is an on-going project, so some sections are built out more than others, and stuff will be continually added to it. Jamaica Villas I just did the development on this one (not the design, other than tweaks). The design they had was very much in line with the Kickstart framework, so I stuck with it when producing in ProcessWire. I enjoyed using it, and was nice to use a framework developed by another ProcessWire user. I've worked on a few other villa sites in the past, and this one is smaller in terms of quantity of properties, though still involved a lot of work. This one has a full calendar and availability tracking system built into it (all running on ProcessWire), so it can search by availability or look at availability calendars and such. So there's a lot of power packed into this one. I just wish I'd had the opportunity to do the full design on this one, but it was still a satisfying and enjoyable project (as most are, when using ProcessWire)
    1 point
  5. I've used twig templates, it's pretty easy once you have the twig bits set up to just call twig to spit out templates from the normal processwire PHP pages. I have recently started a project where I use PW purely as a CMS tool, and then have a totally seperate site (sat side by side on the same server) that uses the PW API to pull data and inject into twig templates. I have used the Silex PHP microframework, but the API is so good you could use it from any PHP code you like. If you want to use PW as a CMS and page-modelling tool and then any other set of code to actually spit out a site to the end user, it's no problem. I'm not a fan of HTML+PHP templates, and a template language like twig is much more powerful and flexible in many ways. Inheritance of templates, sandboxed template tags, ability to create custom tags, caching, very intelligent iteration and filtering/processing to do all kinds of stuff. Not a necessity by any means (and not an insult to PW), just shows that there are many options available that can utilise the real unique power of PW (the page/data modelling and the query API) and then whatever tool you feel comfortable with to build the site. By using Silex, we have very fine control over our site structure. The site URL structure need not mimic how the pages (or generic pieces of data as we see it) are held in the PW page tree. We are basically using PW as a data/page repository (like a big XML document full of data), then using that data in whatever way we like with the API. If you see PW as a data-modelling tool, rather than a page-modelling tool, it opens up a whole new way of thinking about things. Each "page" in PW is really just a unit of data, it need not actually represent a page if you don't want it to. This was typed in a rush as I head out the door, so I hope it makes sense and gives some food for thought!
    1 point
  6. Nobody likes upscaling. But if I call a function asking for it to create something at a certain size, it's because that's the size required. If there are other conditions surrounding that, shouldn't it be left to the caller to decide? i.e. if($image->width > 300) $image = $image->width(300); If not wild about extra arguments (especially booleans) in API functions because they aren't self explanatory in the resulting code. So I'll only use them when absolutely necessary. Whereas, a bit of code like above is self explanatory to us now, and years from now when things like "what does the 3rd argument mean" are no longer fresh on our minds. On the other hand, I've got no problem with self explanatory function names, like widthNoUpscale(), but sometimes adding more makes the API less simple.
    1 point
  7. It's definitely doable with ProsessWire. I guess custom profile edit pages is what will require most of the efforts. Will admin users use PW's backend to edit pages and manage users? If so then it will be a breeze to build, otherwise it will require additional development. Comment module is already present in PW and I remember Ryan mentioned its rework is planned in the future.
    1 point
  8. I checked the FAQs of my host server and it seems like they indeed block certain scripts to increase security. I contacted them and they allowed iFrames and such. Thanks a bunch.
    1 point
  9. Wordpress and Contao are examples for what can happen to a CMS (or blog engine), if it gets too many modules or plugins – every tried finding a good contact form or lightbox plugin for WP? Good luck with that. It'll cost you days. Modules are great for non-expert users (which is why a blog system like WP is more likely to have a lot of them than a "real" CMS), and I admit that there are things I couldn't do in PW in a reasonable amount of time without modules. But in case of simple stuff like a lightboxed gallery, I prefer to have a CMS emit the markup I want and use the lightbox script I want instead of using a module which never seems to emit the code you'd want it to. I'm not sure this "module proliferation" is something you can control beyond a certain point of growth of a CMS or blog system. But as long as it's possible, "one module/plugin per purpose" is something a CMS can really benefit from. I would like to see PW's users adapt such a philosophy – if you intend to write a module, first take a look at the existing modules and see if you can extend one instead of adding (maybe duplicated) functionality via a new plugin.
    1 point
  10. All right, looks like it was my mistake. Including the jCart PHP into config.php does work, if you move the initialization code to the head of your template, which is this bit: // Initialize jcart after session start $jcart = $_SESSION['jcart']; if(!is_object($jcart)) { $jcart = $_SESSION['jcart'] = new Jcart(); } ...and also remove jCart's session_start. Sometimes you just gotta take a break!
    1 point
  11. 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.
    1 point
  12. Very well said Ryan, couldn't agree more. While I know I wouldn't use template language, I think that might well make PW a little bit more beginner friendly. Not sure if it is worth the trouble (vs. writing more tutorials, getting started materials etc..). Also maybe we could cheat a little here, and tell that PW uses templating language called "Wire", which looks like this: Output a variable: <?= $page->title ?> Loop for children: <? foreach ($page->children as $p): ?> <h2><?= $p->title ?> <? endforeach; ?>
    1 point
  13. Just went through this old thread and noticed that there's no link or note here that there is a module for this already. I created the PageEditSoftLock module for this particular problem, with a little help of Ryan to get easy starting. I got it installed in all our PW projects and it won't lock the page completely (still editable) but throw a fat red message and a js alert. It workes very well and has been a saver already a couple times preventing two people editing the same page. It has been released here: http://processwire.c...edit-soft-lock/
    1 point
  14. The page statuses are a bitmask so it's possible for there to be multiple statuses on a page, like unpublished and hidden. So it's best to add and remove statuses with the addStatus and removeStatus functions, i.e. $page->addStatus(Page::statusUnpublished); // same as: $page->status = $page->status | Page::statusUnpublished; $page->removeStatus(Page::statusHidden); // same as: $page->status = $page->status & ~Page::statusHidden; You can also check the status of a page by using the is() function: if($page->is(Page::statusUnpublished)) { ... } // same as if($page->status & Page::statusUnpublished) { ... }
    1 point
×
×
  • Create New...