Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/18/2013 in all areas

  1. At least in ProcessWire, the tree is far more scalable than a linear bucket system like in EE. If it helps to conceptualize, think of ProcessWire as having a tree of buckets. This is the natural way the web works. If a single-level linear bucket system suits your needs, then you can do this in ProcessWire. But there's a good chance you can do much better. So I would argue that your statement about buckets vs. trees is backwards. In terms of scalability, a tree will take you much farther. But it does require that each branch in that tree have the ability to function as an unlimited bucket. This is exactly what ProcessWire does. Also consider that websites have hierarchy by nature, need and design. That hierarchy is extremely useful and powerful, and should be embraced. Websites lacking hierarchy would be limited, for obvious reasons. When working with a linear bucket system, you are always mapping a hierarchal system to buckets. This has always struck me as completely unnecessary, complicated and unfortunate. This mapping and conversion is ultimately a side effect of having to reduce a powerful system of tree hierarchy (upon which the web is based) to a less powerful bucket system. But if the system embraces the natural hierarchy of the web, then no mapping or conversion is necessary. You are working with the tree either way. The question is whether the system is embracing and using it (like ProcessWire), or mapping it to a more limited system of linear buckets. I don't have enough experience with MODX to know what the "resource tree shortcoming is", but am guessing it's something to do with pagination that others have mentioned before? I know that MODX has a reputation for being quite scalable, so would guess that they just have a different approach to managing that scale. But once you have worked with trees, and really experienced the benefits, it's very difficult to go back to buckets, IMO. The words "tree" and "shortcoming" simply do not go together. As for keeping more than one CMS in your toolbox, I think that's always a good idea. It sounds like MODX and ProcessWire have common ground in terms of philosophy, and these two would be good to have in your toolbox. I don't think I would bother with keeping a bucket-based system in your toolbox, except for perhaps WordPress, which can be handy in the right situations (like one-off blogs when client has very limited budget). ProcessWire is pretty much infinitely scalable, within the boundaries of a server, SQL database and file system. As scale increases, you do have to practice care in how you use the API. ProcessWire gives you a lot of power, and will fill up your memory if you tell it to. So you have to use common sense when using the API at the large scale. For example, an API call like $page->children(); might be referring to a million pages. Do you really want to load and display links to a million pages at once? (probably not). Does the server have enough RAM to keep a million pages in memory at once? (not likely). So you accommodate scale by specifying limits and using pagination, like $page->children("limit=50"); This is something you don't necessarily have to consider at the smaller scale. But I think it's a good practice to design and develop every site as if it could grow infinitely. Do you need to learn PHP? Not any more than you would need to learn the {tags} from another system, like EE. The time investment and scope of what you'd have to learn would be about the same, maybe even less with ProcessWire. In fact, you can do almost anything in ProcessWire by simply learning how to use just two API variables: $page and $pages, and knowing what a PageArray is. There are a few bonuses you get from learning PHP vs. a tag system though: Whatever you learn about PHP is something you can take with you, beyond ProcessWire. The more you learn about PHP, the more you can do, both inside and outside ProcessWire. Meaning, the environment can grow with you, when and if you want it to. Whereas, at some point, you'll start hitting your head on the ceiling in a {tag} environment. ProcessWire's API is identical regardless of context. You can be in a template file, command line script, plugin/module, etc., and everything works the same. In a {tag} environment, if you want to grow and learn plugin/module development, you'll be starting from scratch. In ProcessWire, everything you learn applies throughout the system in any context. It's only a small step to go from building templates to building modules. In {tag} systems, it's a canyon. In fairness, while you don't need to know much about PHP to effectively use ProcessWire, you may indeed need to learn more PHP to accomplish some of the things you've set out to do: paid membership and access, member signup forms, etc. ProcessWire is a tool more than a turn-key solution for these particular needs. While they aren't difficult to accomplish, you might find yourself doing more on the code side than you would with a system that has turn-key solutions for membership sites. If your project budget/timeline doesn't give you the room to learn and build these things, you would want to investigate more ready-to-use solutions for these. But I think you would do well to make friends with and use ProcessWire either way.
    12 points
  2. Yes, I merged it to master yesterday. I just don't think there's any reason for new users (especially) to be starting with 2.2.9 at this point. The dev branch is more stable than 2.2.9. Now we can go back to letting the dev branch be a dev branch. I'll send out a 2.3 announcement later this week. While there are always more issues to resolve, there haven't been any major problems since people started testing. Nearly all issues that have come up have been related to needing a modules cache clear, or needing to start with a fresh /wire/ dir–things that people should do for any ProcessWire upgrade. I have now added these items to the upgrade instructions in the new README file included with ProcessWire. People upgrading from 2.2 to 2.3 should still follow all upgrade instructions exactly, backup, use caution and test thoroughly. Here are the upgrade instructions as they appear in that readme file: Best Practices Before Upgrading Backup your database and backup all the files in your site. When possible, test the upgrade on a development/staging site before performing the upgrade on a live/production site. If you have 3rd party modules installed, confirm that they are compatible with the ProcessWire version you are upgrading to. If you cannot confirm compatibility, uninstall the 3rd party modules before upgrading, when possible. You can attempt to re-install them after upgrading. General Upgrade Process If you are upgrading from a version of ProcessWire earlier than 2.3, see the sections below for version-specific details before completing the general upgrade process. Upgrading from one version of ProcessWire to another is a matter of replacing these files from your old version with those from the new: /wire/ /index.php /.htaccess Replacing the above directory/files is typically the only thing you need to do in order to upgrade. But please see below for more specific details about each of these: Replacing the /wire/ directory When you replace the /wire/ directory, make sure that you remove or rename the old one first. If you just copy or FTP changed files into the existing /wire/ directory, you will end up with both old and new files, which will cause an error. Note that the /wire/ directory does not contain any files specific to your site, only to ProcessWire. All the files specific to your site are stored in /site/ and you would leave that directory alone during an upgrade. Replacing the /index.php file This file doesn't change often between minor versions. As a result, you don't need to replace this file unless it has changed. Replacing the .htaccess file Like the index.php file, this doesn't always change between minor upgrades, so the same applies. This file is initially named htaccess.txt in the ProcessWire source. You will want to remove your existing .htaccess file and rename the new htaccess.txt to .htaccess. Sometimes people have made changes to the .htaccess file. If this is the case for your site, remember to migrate those changes to the new .htaccess file. Upgrading from ProcessWire 2.2 Follow the general upgrade process above. You will want to replace your /index.php and .htaccess file as well. Clear your modules cache. To do this, remove all of these files: /site/assets/cache/Modules.* Login to ProcessWire admin. You may get an error on the first web request you try, but that should only happen once, so just reload the page. Upgrading from ProcessWire 2.1 First upgrade to ProcessWire 2.2. (side note: I'm not positive this is necessary, you may be able to go straight to 2.3, but I didn't have any 2.1 sites to test). Follow the instructions above to upgrade from ProcessWire 2.2. Upgrading from ProcessWire 2.0 Download ProcessWire 2.2 and follow the upgrade instructions in that version's README file to upgrade from 2.0 to 2.2. After successfully upgrading to 2.2, follow the general upgrade process above. Troubleshooting an Upgrade If your site is not working after performing an upgrade, clear your modules cache. You can do this by removing all of these files: /site/assets/cache/Modules.* If your site still doesn't work, remove the /wire/ directory completely. Then upload a fresh copy of the /wire/ directory. If your site still doesn't work, view the latest entries in your error log file to see if it clarifies anything. The error log can be found in: /site/assets/logs/errors.txt If your site still doesn't work, please post in the ProcessWire support forums.
    12 points
  3. So you never had to write a snippet by yourself? Because in ProcessWire, things are almost the same - but I think lots of people are scared about using php tags / variables. For example: //modx [[*body]] //processwire <?= $page->body ?> //modx [[getResources? &parents=`1000` &sortby=`created` &showHidden=`1`]] //processwire $pages->find('parent=1000, sort=created, include_hidden=1'); Cheers
    5 points
  4. Shadow fields? They inherit everything but name/label from some other field. Thus they can be used on same template as their "parent". Not that I like it (I don't), but it would probably be one solution for this kind of issues.
    3 points
  5. How about this? $array = array(); foreach($page->repeater as $r){ $array[] = <<<EOT <div> <h2>{$r->headline}</h2> <p>{$r->body}</p> </div> EOT; } foreach($page->images as $i){ $array[] = "<img src='{$i->url}'/>"; } shuffle($array); foreach($array as $a){ echo $a; } edit: the forum editor seems not to approve the heredoc sintax, and because I don't want any conflicts with it, here is the alternative way $array = array(); foreach($page->repeater as $r){ $array[] = "<div><h2>{$r->headline}</h2><p>{$r->body}</p></div>"; } foreach($page->images as $i){ $array[] = "<img src='{$i->url}'/>"; } shuffle($array); foreach($array as $a){ echo $a; }
    3 points
  6. I pretty much explained why I left modx evo for processwire in a reaction to a post made on the modx forum and also added my 2 cents to the discussion on Marc Hinse's site . What started me was that I ran into php 5.4 troubles on my modx evo sites and therefore started looking around. Then I had one site ported from modx evo to processwire, and now I have decided to move all my modx evo sites to processwire. PW is extremely fast, I use the procache module. I also use lots of different sized pics on some of my sites and the thumbnails module just is incredible, it makes life sooooooo much easier in the front end, I can not even believe anymore how I used to crop and resize all different images offline and upload to different TV's in modx evo. I now just upload one image and the module does it all and allows me to choose the cropping. Do I sound enthusiastic? Sorry about that, but I am! Thanks Ryan, for a brilliant cms/cmf and thanks to the great people on board who are really making this thing a really kick-ass seo cms! I am not a developer, not a designer, I just get people to port a design I like and then fiddle around with the html so it ends up high in the serps. OFcourse there is more to it than that, but for what I need I want a csm that allows me to change anything and everything with ease. ANd now PW even has a heatmap module, can you believe what that means for tweaking your bounce rates and visitor retention? Ah well, better stop now. Processwire is GREAT!
    3 points
  7. $location_cat = $pages->find('template=location_category'); ...and then your foreach.
    3 points
  8. @teppo WoW thanks for your code, it worked perfectly! Didn't know about the .isFunction. Commited version 1.0.3 to GitHub. The user needs permission 'batcher' to see the page in admin. If you update, please create the permission manually and add it to the user role. (Thanks Soma for the hint!) Fix javascript to support jQuery .live function for older Pw installations
    3 points
  9. I'd just like to debunk this FUD, cause that's what it is. EVO is now a community supported CMS and a new release is actually in the works by maintainers of several now-dead forks. If it was killed, the download wouldn't be available on the MODX website today. But with limited resources there's no way MODX LLC can actively develop and support 2 major CMSs and while I don't want to claim that the Evo to Revo transition was handled properly, saying that a "kill switch" was pulled on Evo is simply wrong. Slowed down and focused on Revo, yes, killed, no. I don't agree there's difference between an Evo and Revo user profile either. As for MODX 3.0... it will be a continuation of Revolution, but taking a step back and looking at what it is that still attracts people to Evo and what people are asking for, and incorporating that into Revo. Speedier & slimmer core. Content elements instead of resources and TVs. Easier manager customisation. Easier ACLs. There will be no "kill switch" pulled on Revo when 3.0 as we've never done that. It'll be deprecated (as any old version is), but that doesn't mean you're out of luck if you need help with it, and I'm sure there'll still be a couple of maintenance and security releases as needed. The beauty of MODX 3 is that it will be the first time that, following semver rules, actual breaking changes can be introduced since the release of Revo in 2010. And 3.0 will become the priority this year and you'll hear lots more about it after we release 2.2.7. Aaaaaaaaanyway, kinda off-topic here, sorry for that. Yes, you should make friends with ProcessWire because frankly it's a kick-ass CMS with a great community. I'm sure it's very scalable because of the way it is architected (I bet there's a thing or two we could learn from PW for MODX too!) and from what I've seen it's quite extensible too in case you need to move beyond it's core features.
    3 points
  10. Gebäude alles klar gedanken versunken! Tschüüüss
    2 points
  11. I just asked google for a "cms with custom fields"
    2 points
  12. Name them this way: description_person description_job would keep them together on normal view. You also might benefit from new field tags introduced on 2.3. I am not sure I understand your concern well enough, but for me namespaces in fields sounds like overengineering and would complicate it. KISS
    2 points
  13. We should have a subpage of the website calles "Ryan's collected words"
    2 points
  14. Done on couple sites, but here's a suggestion. Ryan, if you want to get up high in the serps for certain phrases, why not add this as a module to PW: Add a special attribution module In which you: 1- choose the keyword phrases you want to rank for 2 - make sure these are used in (random or you specify the weight) variation in the attribution phrases and let your module take care of the variation Reason you want anchor text variation is to guard against G's - over-optimisation penalty, which means do not get all anchor texts to be the same, because in the end this will seriously hurt your rankings. I forget now, but there was an example of a big site that I think sold templates, who got ditched for their seo rankings simply because all sites out there linked back to them with one anchor text term, which led big G to believe they over-optimised their back links and wham, they got the penalty and went way down the serps. If you make this a module that does it all on automatic, you could even update the module to keep on checking your anchor text variations and bring your backlink-profile in line with what you want to rank for. Just my 2 cents.
    2 points
  15. I heard about PW by reading a post on the Textpattern forum (which was my previous 'main' CMS). After implementing my first PW site, I never switched back to Txp ;-)
    2 points
  16. Since this seems to be only place where you're using .on(), you could also check for it's existence first and provide a fallback in order to support both versions: var remove_tr = function() { ... } if ($.isFunction($(this).on)) { $(document).on('click', '.remove_page', remove_tr); } else { $('.remove_page').live('click', remove_tr); } Not properly tested, just posting it here as a rough idea.. Another thing you could do (though it'd still make sense to use .on() if it's available) is replacing .live() with .delegate(), which was added in 1.4.2 and even though it's been effectively deprecated by .on() it still exists in new jQuery versions: $(document).delegate('.remove_page', 'click', function() { ...});
    2 points
  17. Hi Jan ProcessWire is hugely more flexible that Wordpress and you don't need to know much php at all - in fact, the ability to copy and paste is probably more important! (Especially with all the help round here). There is no strict theming system for ProcessWire in the way you would think of for Drumlapress (!) - basically because that would limit the creation of bespoke websites far too much. The system as it works now means that as long as you can write good HTML and CSS, you can create a brilliant site, without having to learn a templating system. You can more or less approach it in the same way as you would a static site - though, of course, you can get a lot more clever too. If you are looking to integrate it with a framework, then that is as easy as it is with a static site. But, so you get the idea, here is is a veyr stripped back basic profile using Bootstrap: http://modules.processwire.com/modules/bootwire-starter-profile/ As for things like galleries and other plugins, because of the way the site is constructed you can integrate ANY plugin without worrying about it having to fit in with the way the system works. Since there is NO JQuery or anything else for the front end until you actually put it there, you wont run into any conflict trouble with anything supplied by ProcessWire. You simply go and install the plugin in the way the developer says and then learn some very basic php and PW syntax to encorporate your data. Galleries are so simple that it is a joke. As for things like blogs - if you want something very simple (a basic "post some news" sort of thing) then it is so easy to create your own system to work the way you want it to. So, all in all, although it would not be of instest to the average Wordpress user, for any designers out there, it is the perfect way for them not only to design what they want, but in the process learn some basic development skills, which never goes amiss! I am a prime example - I am a copywriter, composer and advertising guru, and yet I am creating my own, very complex blog profile, have created several complex brochure site systems and am learning like mad. I strongly suggest you read the following: Showcase: http://processwire.com/talk/forum/9-showcase/ Detailed beginners tutorial: http://wiki.processwire.com/index.php/Basic_Website_Tutorial (written by me who is not a dev) Explanation of Pages: http://wiki.processwire.com/index.php/Pages You will also find that although there is some serious knowledge amongst the community here, not all of us are developers - but all of us have been surprised how much we have learned. Stay and enjoy! Joss
    2 points
  18. Hello guys, Iam Jan a web/graphic designer from germany. For the last 2 weeks I was searching for a great cms soulution for small to medium-sized companies. My customers are artist, photographers, small agencys or startups. I really like the way PW works, because it seems like I can design everything and dont have to force the design in the system. I can write HTML/CSS and can implement JQuery as I would do on a static website, than I can make it dynamic using PW. Still there is one thing I struggle with, and thats to lern PHP. Iam by no means a programmer and I will never be one. I can see me learning the basics but would like to write PHP code as little as possible. I have tryed Wordpress for a small website and while I think PW is a much better/cleaner solution, I do like how it handels themes, plugins and backend UI. For me the plugins can really save me some time in using functions, that I would never be able to implement on my own or with a lot of work. To reach the Wordpress audience, there are some things that need to work better in PW in my opinion. -Easy export/import of themes/profiles without using modules -Showcase of themes/profiles on the PW site -HTML framework integration (e.g. Bootstrap, Kickstart, 960grid) and showcase on the website. -A simple Blog module. I know there is the Blog Profile but it seams a little to complicatet for me. -A gallery module with JQery integration. That would be great for the not so tech savvy design guys like me and other WP users. -Also a starter Tutorial on the Website (not the Forum) or a tutorial section would be cool, as some tutorials can be hard to find for a newbie. -The button view in the backend when you hover a page is not nessesary in my opninion as you can view it unsing the button on the top when you in edit mode. The first Option here should be edit, as thats would a normal user would do in most cases. Anyway I realy like PW and looking forward to use it on future project. Thanks for reading Jan
    1 point
  19. Hi this is my new onepager site for the thesouplibrary.com using: processwire jquery scrollto.js parallax.js
    1 point
  20. Hi lucky, For OR use the pipe | symbol. So, if you want pages that have one of three templates, do this: $location_cat = $pages->find('template=location_category|spot_category|another_category'); This is documented here http://processwire.com/api/selectors/. A great read
    1 point
  21. 1 point
  22. Mercy, aber ich such keinen hoster, ich bin mein eigener. Mir geht es um die Ausführungsgeschwindigkeit von pw, deshalb die Frage nach der Umgebung und ob caching aktiviert ist. Danke für die Infos. adios, stefan
    1 point
  23. My schools website was my first pw project, too: http://sgym.de
    1 point
  24. We're right now building a new website for school. We started about 1.5 years ago and by then there were some good CMSs out there but none seemed to fit. Concrete 5 would have been an option but the version we tried was not usable at all .. So we went for a custom solution built on CodeIgniter which right now is about 2 GB in size Using a framework right now I would go for Laravel 4, however .. Still interested in CMSs I searched the web from time to time and discovered PW on the CMSCritic page. I actually didn't want to try it for some weird reasons (don't know anymore) but the SkyScrapers demo really got me. Last week I started building our site in PW again and it's soo fun. Really, I love it. Going to ask the team on friday but I know they'll love it as well
    1 point
  25. The channel is not crowded enough! Let's take on #jquery =)
    1 point
  26. You are not doing anything with the image, you are just applying the size method without assigning it to anything. The method actually returns that thumbnail, so use it like that: <?php if ($page->children) { foreach($page->children as $selectedthumbs) { $firstimage = $selectedthumbs->selectedimages->first(); $thumb = $firstimage->size(100, 100); echo "<a href='{$selectedthumbs->url}'><img src='{$thumb->url}' alt='{$firstimage->description}'></a>"; } } ?>
    1 point
  27. Doesn't look like an AdminBar issue to me. I Did a really quick test with 2.3 & AdminBar and everything seems to work great. Was able to upload images, edit descriptions and reorder images right there before saving. Using MAMP with PHP 5.4.4.
    1 point
  28. (I'm slow, so probably some of this has been said before, sorry.) One reason would be complexity, like Antti said. Adding one level of abstraction on database level doesn't sound like it's going to make things faster, does it? But I must admit I've been thinking about field naming for a minute of two myself without being able to come up with a solution that feels like it's perfect. I've even gone down that "templatex_fieldy" route more that once and it really fits in sometimes, not that I'd recommend it in general though. There are multiple ways of doing things and while it really is a good idea to have generic fields like you've described, it's not necessarily the way to go all the time. And I don't think any of the previous comments were meant to imply that. This I have to disagree with, a bit . I wouldn't describe a repeater "just a container", but that may have something to do with the fact that I've had to debug the code in the early stages of repeaters to solve a performance issue. It sure is a container for *data* but not so much for fields (yes, it's possible to look at this from another direction too). So, in my opinion, complexity is the key once again. I do like the idea of "max items" option for repeaters and that actually would give you one kind of namespacing by setting the limit to 1, but I wouldn't use that as a solution for the problem you've brought out. Not in large scale anyway. Actually what bothers me most with this is probably the name; if the fieldtype is designed for repeating content, shouldn't that alone be good enough reason to at least reconsider whether it's a good fit for namespacing? Yes, I was also a bit surprised to see how easily this conversation went down one particular route. There was more in the topic that just the example you used. Unfortunately I can't give you any more tools to handle things like namespacing or preventing excess of fields than the other guys did. But that doesn't mean I'm thinking there's only one way to do things. I think grouping of fields in the admin does solve a part of the problem (via tags or prefixes) but also I have a feeling there necessarily isn't an easy way to have a short and neat list of reusable fields if the site itself is complex. I'd be happy to see someone prove me wrong though .
    1 point
  29. Hi Wanze - many thanks - great and simple solution, nice thinking! here is how i finally implemented: <?php $tags = $pages->find("template=tag"); foreach($tags as $tag) { $c = $pages->count("template=audio, tags={$tag}"); if ($c == 0) continue; ?> //filter <li> markup here <?php } ?>
    1 point
  30. Ryan, this is one of those answers that should be visible outside the scope of a forum thread. I went to check how you personal blog is going, and it turns out the last post is from July 2011. How is this possible if from then on you wrote a lot of invaluable information and opinion texts on the forum??
    1 point
  31. Greetings, Excellent post Ryan! I wish the forum had a "Like Very Much" button! Thanks, Matthew
    1 point
  32. If it would be more complicated it wouldnt be processwire ... Thanx a lot!
    1 point
  33. Maybe something like this could work: $tags = $pages->find('template=tag'); foreach ($tags as $tag) { $c = $pages->count("tags={$tag}"); if ($c == 0) //... this tag was not assigned to pages, so don't output it with your filter }
    1 point
  34. On the sort, in the find() statement you can add a sort=created or sort=-created depending on which direction you want to head. Have you got page numbers turned on for the news index template?
    1 point
  35. Anyway, not really the place for a ModX discussion! (Particularly as I have never used it and am far too busy learning ProcessWire...) And I am sure ModX will do very well - they have a pretty good reputation from the little I know and I imagine they will support their users to the full. So, back to the original topic... Sparrow, I think you will enjoy PW very much. I don't have a dev background (or even much of a designer background), but I have learned a huge amount just by playing with PW - it is proving a surprisingly good way of learning PHP. Not that you need to learn a huge amount, but it gets quite addictive after a while.... You have made me think that a tutorial on creating a membership system would be a really good idea. But since I haven't the foggiest how to do it, bear with me while I get a couple of the guys here to teach me, and then I will write it up! Oh, and others have said, scalability is not an issue with PW - even on small sites it seems to take far less server resources than some equivalents, so that gives a good indication that it will pack the punch you desire. Your biggest issue in that regard is probably finding the right host, to be honest. Good luck! Joss
    1 point
  36. update my post to version 0.0.2 with some little changes in tracking method.
    1 point
  37. I am frequent nettuts+ reader, so I read this article about PyroCMS and because I was looking for a better CMS solution than all the semi ideal ones out there, it got me interestend. But then I read the comment by Viktor: http://net.tutsplus.com/tutorials/php/whats-pyrocms/#comment-810229080 Never heard about PW before. I came here and instantly had the feeling this might be MY CMS ... so it happened.
    1 point
  38. 1 point
  39. Updated version of this module just found its way into GitHub. Now there's a config option "Enabled templates" letting you choose the templates you want the "References" tab to be added to (when editing a page with those templates). If no template is chosen, "References" tab is always shown. Templates with system-flag are always skipped, like fields with system-flag have been from the beginning.
    1 point
  40. I think your news functions file is missing the <?php tags
    1 point
  41. you have "page-edit" permission in module info. So my editor can see it. Is this intentional? Could you change it to "batcher" or something to give it to users instead?
    1 point
  42. I didn't realize they were stopping with modx revo? What will their product be then?
    1 point
  43. Hello jploch, Welcome to Processwire forum. Just like you, I'm also a designer & I've clients of similar kind like yours. About 2 years ago, I was looking for a CMS which allows me to design dynamic websites but with my own design. I started Drupal(the very first CMS I tried), Joomla, Wordpress and almost 20 other free CMS but I could never get the required control on HTML. But then I started using Textpattern which is really really simple CMS one of the best solution for small to mid sized websites. I'm still using it, its been almost 2 years now. Textpattern is great when it comes to designing, just like Processwire, you have complete control on the design. But when it comes to making something that's out of CMS's limitations, you need a solution like Processwire. I'm just a week old with Processwire and already loving it so much that I'd probably give second thought to using Textpattern to any of my next projects. With Processwire, the possibilities are unlimited, you are never restricted to doing anything. Everything's just perfect, atleast for me it is. This is an honest reply from a designer, I hope this helps you in some way.
    1 point
  44. Also want to add that it's a pretty simple matter to take a theme (like a WordPress theme) and adapt it to ProcessWire.
    1 point
  45. thanks, for pointing out the difference between the two systems. I have a better understanding now of how PW works. For me its way more important to make custom websites, have the freedom to design anything I want and have a clean code, than selling themes. So PW is obvious the better choice for me. Cant wait to start working with PW now
    1 point
  46. Hey jploch! Joss and onjegolders just said it! Actually my profile would sound quite similar to yours: designer with zero PHP knowledge - and little motivation to do so (though it grew once I started using PW). And I‘ve already bought a book about PHP in the first place, cause I was expecting lot of PHP to handle PW. But it turned out as Joss said: for solving problem I visit the forum or look around in the PW-API or About section - and I find the solution(s). I'm still learning an still working on my first to websites - which both were static and pretty close to finished when I decided to make them dynamic via PW. But being independent from themes, plugins or whatever makes PW so much fun to work with. PW works exact the way I always thought CMSs would work (but they didn't, as I found out). So I would suggest: give PW a first try - and try to solve your needs by getting galleries and blogs to work just simply using PW. I'm sure - with the help of this forum - you will succed. (I'm hoping the same for my projects. )
    1 point
  47. Brilliant answer Joss, said everything I wanted to as usual. Welcome Jploch, as someone who approached PW with little or no PHP, believe me you only really need to learn the very basics to get going and once you start it'll make you want to learn more. I would say that WP is ideal for non-designers. If you're a designer, surely you don't want you or your clients to be messing with changing themes? You want to be free to code what you want and then hand it over to a client. Give PW a try, I think you'll find it's a perfect fit for the sort of work you do.
    1 point
  48. 1.) He's using Joomla. He can't understand this. 2.) It's not about the number of features. Actually, the less, the better- are you really using all of them? 75% of them? 50% of them? 3.) Years of testing… Right. (come on. If anything has 100% of code years-tested, it's probably outdated) 4.) Want to do it different way than your precious module? Yea, fuck you. [This is 95% applicable for WP/drupal as well) --- With building on huge CMS + modules, you end up doing a lot of compromises, which I'm not willing to do. And those are also the bad compromises, the ones users see (unlike e.g. Rails, which makes do stuff his way, but output and experience are in your own hands) --- Ultimately, I'm not selling my clients my ability to stick modules together. I sell the best possible website (in terms of Bussiness Goals and UX) I can create.
    1 point
  49. Based on what I'm understanding from your last message, I think you should skip keeping the separate table. It just sounds like extra, unnecessary work, unless there's something more to this project that I don't yet understand. Instead, I think you should have your cron job execute a script that bootstraps ProcessWire and takes care of all the adding, updating and deleting of records consistent with the web service you are reading from. This is something that I think ProcessWire is particularly good at, because it's been designed for this from the beginning (it's something I have to do with a lot of my client work). Whether XML or JSON doesn't matter much, as PHP includes the ability to read from either type quite easily. Though like the other guys here, I generally prefer JSON just because it's less verbose and less fuss. If JSON, you'll pull the feed and use PHP's json_decode() to convert it to an array. If XML, you'll use PHP's SimpleXML to convert it to an array. Once you've got the array of raw data, you'll iterate through it and add, update, or delete pages in ProcessWire to make it consistent with the data you are pulling from the web service. Live, working example I think that the best way to demonstrate it is with a live, working example. This one uses the existing modules.processwire.com/export-json/ feed. You might also want to see the feed in human-readable mode to get a better look at the format. Below is a shell script that bootstraps ProcessWire, reads from that feed and maintains a mini "modules directory" site, on your own site. I made this feed so that it can be tested and used on a brand new installation using the basic profile (included with PW). If left how it is, it'll create a mini modules directory site below the '/about/what/' page and use the template 'basic-page' for any pages it adds. But you can run this on any ProcessWire installation by just editing the script and changing the parent from '/about/what/' to something else, and changing the template from 'basic-page' to something else, if necessary. This script assumes that the template used has 3 fields: title, body, and summary. The 'basic-page' template in PW's default profile already has these. If you adapt this for your own use, you'd probably want to change it to use more specific fields consistent with what you need to store on your pages. In this example, I'm just building a 'body' field with some combined data in it, but that's just to minimize the amount of setup necessary for you or others to test this… The purpose is that this is something you can easily run in the default profile without adding any new templates, fields, pages, etc. 1. Paste the following script into the file import-json.php (or download the attachment below). For testing purposes, just put it in the same directory where you have ProcessWire installed. (If you place it elsewhere, update the include("./index.php"); line at the top to load ProcessWire's index.php file). 2. Edit the import-json.php file and update the first line: "#!/usr/bin/php", to point to where you have PHP installed (if not /usr/bin/php). Save. 3. Make the file executable as a shell script: chmod +x ./import-json.php 4. Run the file at the command line by typing "./import-json.php" and hit enter. It should create about 95 or so pages under /about/what/. Take a look at them. Run it again, and you'll find it reports no changes. Try making some changes to the text on 1 or 2 of the pages it added and run it again, it should update them. Try deleting some of it's pages, and it should add them back. Try adding some pages below /about/what/ on your own, run it again, and it should delete them. import-json.php #!/usr/bin/php <?php // replace the path in the shabang line above with the path to your PHP // bootstrap ProcessWire. Update the path in the include if this script is not in the same dir include("./index.php"); // if you want to run this as a PW page/template instead, remove everything above (except the PHP tag) // save our start time, so we can find which pages should be removed $started = time(); // keep track of how many changes we've made so we can report at the end $numChanged = 0; $numAdded = 0; $numTrashed = 0; // URL to our web service data $url = 'http://modules.processwire.com/export-json/?apikey=pw223&limit=100'; // get the data and decode it to an array $data = json_decode(file_get_contents($url), true); // if we couldn't load the data, then abort if(!$data || $data['status'] != 'success') throw new WireException("Can't load data from $url"); // the parent page of our items: /about/what/ is a page from the basic profile // update this to be whatever parent you want it to populate... $parent = wire('pages')->get('/about/what/'); if(!$parent->id) throw new WireException("Parent page does not exist"); // iterate each item in the feed and create or update pages with the data foreach($data['items'] as $item) { // see if we already have this item $page = $parent->child("name=$item[name]"); // if we don't have this item already then create it if(!$page->id) { $page = new Page(); $page->parent = $parent; $page->template = 'basic-page'; // template new pages should use $page->name = $item['name']; echo "\nAdding new page: $item[name]"; $numAdded++; } // now populate our page fields from data in the feed $page->of(false); // ensure output formatting is off $page->title = $item['title']; $page->summary = $item['summary']; // To keep it simple, we'll just populate our $page->body field with some combined // data from the feed. Outside of this example context, you'd probably want to // populate separate fields that you'd created on the page's template. $body = "<h2>$item[summary]</h2>"; $body .= "<p>Version: $item[module_version]</p>"; foreach($item['categories'] as $category) $body .= "<p>Category: $category[title]</p>"; $body .= "<p><a href='$item[download_url]'>Download</a> / <a href='$item[url]'>More Details</a></p>"; $page->body = $body; // print what changed $changes = $page->getChanges(); if(count($changes)) { $numChanged++; foreach($changes as $change) echo "\nUpdated '$change' on page: $page->name"; } // save the page $page->save(); } // now find pages that were not updated above, which indicates they // weren't in the feed and should probably be trashed $expired = $parent->children("modified<$started"); foreach($expired as $page) { echo "\nTrashing expired page: $page->name"; $page->trash(); // move to trash $numTrashed++; } echo "\n\n$numAdded page(s) were added"; echo "\n$numChanged page(s) were changed"; echo "\n$numTrashed page(s) were trashed\n"; import-json.php.txt Running the script as a cron job: You can instruct your cron job to run the script and it should be ready to go. You may want to move it to a non web accessible location for more permanent use. You'll also want to update your bootstrap "include()" line at the top to have the full path to your ProcessWire index.php file, as your cron job probably isn't executing it from the web root dir like you were manually. Running the script as a template file: You can run this script as a template file on a page by removing the include() line and everything above it with this line: <pre><?php Place it in your /site/templates/ directory, add the template from PW admin, and create a page that uses it, then view it.
    1 point
×
×
  • Create New...