Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/20/2013 in all areas

  1. Because I’ve never been really happy with the current strategies (I know) to deliver images the right solutions in responsive layouts, I lately started to work on my own approach. Other solutions like for example Wilcox’ Adaptive Images just rely on the screen resolution/window size or require additional (and manually added) data attributes or even js/noscript hacks in the markup. For me it was important to have a solution, that is installed once and then just works. So I took some ideas from other stratgies and put something together that seems to work so far (but I still have to test it in older browsers). Feel free to give it a try. I’d love to get some feedback on this. For detailed info have a look at the README. https://github.com/oliverwehn/Responsive-Images
    4 points
  2. I'm quite new to PW, what a great platform, everything makes so much sense! First night I couldn't sleep, was so excited about it Small question here: I have a couple of templates, they all include the 'title' field, because it is set to 'Global' (and system as well) and it makes of course sense to have to everywhere. But in one template I'd like to hide it, which can be done with the visibility setting. But then it is of course empty! Is there a solution to populate this field with two other fields, for example having a person template, field and contents first name "John" last name "Doe" academic degree "Dr." and the title of a combination of those three values set to "Dr. John Doe"?
    3 points
  3. 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
    3 points
  4. Welcome. Well I can't sleep since two years because of PW There's a concencate module by Ryan that would allow to combine fields to a runtime value. You can open title field and make in unglobal and remove it from the template you don't need. PW requires only a "name" which is like an id. Have fun and sleep well!
    3 points
  5. Looks great, looking forward to it, though I have to say I keep coming back to Ryan's original admin theme.
    2 points
  6. 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.
    2 points
  7. 2 points
  8. Greetings, See this post -> http://processwire.com/talk/topic/1358-repeater-inside-itself/?p=12139 Thanks, Matthew
    2 points
  9. Strangely, I was looking this up yesterday! Doesn't that limit characters? If you want to do words: $text = implode(' ',array_slice(str_word_count($post->summary,1),0,$maxpostlength)); Where $maxpostlength is the number of words and $post->summary was the field I wanted to truncate.
    2 points
  10. On your second point, I would always go the two field direction - it makes it very clear to the user what they are expected to do and you can have fun later. You can add custom classes to TinyMCE on the configuration for the field, though you need to be very specific with your needs. Generally I would avoid unless there is something special you want to add. You can also use JQuery to add classes to specific elements, as long as you have them identified clearly enough. As an example, I use that to add the class "fancybox" to all <a> tags that are wrapped around images within a certain area of my template. $('.blogpost img').closest("a").addClass("fancybox ").attr('rel', 'group'); That finds an img tag within my blogpost div then adds a class and attribute to the closest a tag. Then, in tinyMCE when you add an image, just make sure that you tick the "link to larger image" in the image modal. However, most of the time, things like my main images are separate fields and not added to the text in the form - again, it is clearer that way and less likely to cause issues. ###### On your first point, I am not totally sure why you need a repeater, so I will ignore that for the moment! It is perfectly fine to let the user choose an icon for the beginning of a title, or whatever. While it is important to control how creativity affects the layout of a site, you shouldn't stifle it either unless they have a full time editor to do the hard work! Just use a Page field for this job. Create a hidden page somewhere on your page tree and call it Icons. Give it a template that has no file associated with it. Now, create a series of pages - each title field represents an icon. Create a pages field for your article template - it should be for a single select (third option on details) and just a normal select box on the input tab. Select your icons page as the parent. When you create a new article you can select the icon from that page field. In your template, just set up a series of conditions referencing the page field. if($page->page_field->name = something) { echo "My Icon"; } and work your way down the list. You can read more on using the page field for creating select lists here: http://wiki.processwire.com/index.php/Page_Field If you want your reference to be different from the title in the drop down (if your titles are a bit descriptive, perhaps) then create a second field in your icons page and use that for your reference. Does that help? Joss
    2 points
  11. Okay, it's not that complicated: Creating a shortcode in code Like in my example above you could for example create a sitemap like this: <?php $shortcode->add('sitemap', function($atts){ if($atts['page'] == '') { $atts['page'] = wire('pages')->get('/'); } else { $atts['page'] = wire('pages')->get('name='.$atts['page']); } function sitemapListPage($page) { echo "<li><a rel='follow' href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) { echo "<ul>"; foreach($page->children as $child) sitemapListPage($child); echo "</ul>"; } echo "</li>"; } echo "<ul class='sitemap'>"; sitemapListPage($atts['page']); echo "</ul>"; }); ?> It's important to use wire('pages') instead of $pages inside the function. Same for wire('config'), wire('input'), ... Use the shortcode At first you have to add [sitemap] inside your textarea. You don't need to activate something spacial like TinyMCE or so for it. Just put [sitemap] or [whatever] (if you have something like "$shortcode->add('whatever', function($atts){ });") inside your textarea or textfield. It won't work automatically. You have to use the function in your template field: (if your fields name is "body") $shortcode = $modules->get('MarkupShortcodes'); echo $shortcode->render($page->body); Any questions left?
    2 points
  12. Edit: see what Soma suggests below. That's the clean way. I've managed to overcomplicate things, again
    2 points
  13. Here's a part of my latest code. Should help: (I added some comments) if($input->post->save) { $gallery->setOutputFormatting(false); // Get the path for the temp file $tmp_path = $config->paths->assets.'tdotTmp/'; // Create the temp file $filename = $tmp_path.time().'.png'; $handle = fopen($filename, 'w+'); // $input->post->dataUrl is the base64 encoded png image // This line replaces the "image/png;base64," to get the raw base64 $uri = substr($input->post->dataUrl,strpos($input->post->dataUrl,",")+1); $encodedData = str_replace(' ','+',$uri); // Decode the base 64 data $decodedData = base64_decode($encodedData); // write the encoded data in the tmp file fwrite($handle, $decodedData); fclose($handle); // Upload the temp file as a new file in the gallery $gallery->upload_image->add($filename); $gallery->save(); }
    2 points
  14. I've been wanted to start this theme for a while because ever since I first heard of ProcessWire I felt it needed a really calm theme, one void of clutter and noise. While I may have taken this one to the extreme, I'm hoping some will find it's simplicity refreshing. It will be optimised for mobile devices and you can customise the colours, even the grey. I look forward to posting more of my progress!
    1 point
  15. As you maybe noticed, FontSquirrel doesn't have a custom preview text on the font list. I just found a very neat extension to take care of this https://chrome.google.com/webstore/detail/fontsquirrel-preview/amjelmhhimmobojbpoccmilajoalncem
    1 point
  16. So why am I posting a profile in the pub? Well, it is currently so drunken that this is where is belongs. Also, it is a long way off being finished.... Sooooo The Bootwire Blog (of course) is a bootstrap / processwire blog profile that I have started from scratch, more as a learning exersise as anything. And it has certainly given Soma a good work out so far! It is sort of gone a bit beyond a blog, to be honest, and is rapidly turning into a magazine site. It has some interesting features: Categories Topics Tags Post types Authors Choose side bar items globally, or for all category pages, or for all topic pages Choose side bar items (widgets) for any single post Choose themes for posts Posts can have simple galleries added Choose themes for the site (very limited themes to be honest) Centrally control things like headers/footers, number of recent posts to list, lost of other things Posts can be featured on the front page and/or on their own category. Lots of other things. My basic premise that I started from is: 1. Everything is a post 2. Every post belongs to one category 3. Every post can belong to multiple topics 4. Every post can have multiple tags 5. Posts types are based on different templates 6. Themes can be applied to any template 7. Post are also listed by template type. Post types will include: Standard Blog Video Blog Reviews Recipes Photo Blog and so on. The way the categorisation works is quite complicated. But dont worry - here is a huge piece about it! The blog uses five sets of criteria to organise information: Categories Tags Topics Post Types Authors CategoriesThese are the most obvious form of organisation as they make up the main menu hierarchy. On this particular "hover" menu, all categories can accept posts. However, the click-to-open menu version cannot have posts associated with the top level since the top levels will no longer link anywhere. Consequently, it is difficult to switch from one version of the site to another without causing a lot of headaches! Generally it is best to organise the categories into obvious trees: Politics, Sport, Media and so on. Each category can have more than one child creating multiple branches from one top level category. However, making this too complicated or the categories too many layered could be problematical. (note, if this is for touch devises such as phones, too many levels will make it frustrating to navigate. TagsTags are very much what you would expect - single keywords or short phrases that can be associated with posts on a many-to-many basis. Clicking on a keyword creates a seach of keywords on the database.. There is no limit to the amount of keywords that can be created, but it makes sense to re-use keywords as much as possible! TopicsThis is a departure from the normal way a blog or news site works. Topics are broad subject areas that might be related to one particular category, but can be used by any post in any category. For instance, a topic might be created that explores the politics surrounding what we eat. That topic would be of possible use in both the Politics category and the Food category, depending on the post. Topics are far more detailed than tags, but they are limited in number. Unlike tags, they cannot be created on the fly, but are created centrally by the site editors to reflect the nature of the site. A post can be associated with more than one topic, though this may be unusual. Topics will often have long titles and could have long descriptions. A post can optionally display the full topic details in the side bar. Post TypePosts are separated into templates. The most common template is the standard blog which is similar to a Blogger or Wordpress blog. However, further templates are available for perhaps a photo blog featuring a single blog, a full blown gallery blog, a video blog, a review blog, a recipe blog and so on. These Post Types have different layouts and fields that suit their particular subject matter and bring the subject of the post to the forefront. Posts can be sorted by post type. AuthorsObviously, posts have authors. And posts can also be sorted by their author! Well, that is about it at the moment. I have got as far as getting the standard posts, the categories the widget system and the tag system working together with search. I am starting on topics (which I need to think carefully about - not from the tech view, but from the librarian point of view) and will then wonder onto comments. I am going to try and put both the normal system of comments on, but allow for disqus to be used instead. It currently looks like the following (sorry, it hasn't got enough posts in yet, so it is full of holes!) More to come over the next week or so. Joss
    1 point
  17. 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
  18. I'm in the middle of this one http://www.larryullman.com/books/php-advanced-and-object-oriented-programming/, and liking it a lot.
    1 point
  19. No, I'm from Berlin and 17 so I don't have a car. But I saw this picture and thought it is a good example
    1 point
  20. I think you're getting it wrong, and Joss wants this instead: foreach ($pages->find("template=$page->template") as $p) { echo $p->name; }
    1 point
  21. I believe he means Deutsch site, which loads fine for me. That or he wants to populate douche.processwire.com?
    1 point
  22. Bit sad really. I liked the oval metal badges that you bracketed onto the rear bumper and the front grill. Had a touch of class!
    1 point
  23. You could go with simple text replacement. Lets say you wanted the icons in the body (though it wouldn't matter what field). You'd just instruct the client to visit this page and select the icon they want. That page shows both the icon and the name. You would have them copy the name and then paste it into their copy, wherever they wanted it to appear. Then in your template code, you'd run $page->body through something like this before outputting it: if(strpos($page->body, 'icon-') !== false) { $page->body = preg_replace('/\b(icon-[-a-z]+)\b', '<i class="$1"></i>', $page->body); } So if the client typed this: They'd get this in the markup (which would display the relevant icons): This would be another case where you could use simple text replacement before output: $page->body = str_replace("<h3>", "<h3 class='someclass'>", $page->body); Though if you needed to support different kinds of h3 tags or classes in that copy, then you'd probably want to use TinyMCE advanced settings to setup the 'styleselect' option. This would also be a good option: just targeting those specific h3's with a CSS selector. I think I'm going to go grab some icon-coffee.
    1 point
  24. Just thinking of all the badges on the back of cars when we went on holiday throughout Europe when I was a kid. Spotting those from the same country as us GB. Mind you - they were easy to find. We were the ones driving on the wrong side of the road!
    1 point
  25. Depending on what the site is achieving, SEO can be of very low importance. Take my site http://www.dancingbear.co.uk - although on very specialised keywords it performs incredibly well, I have only once got work directly from the site. My audience is too specialised and still rely on professional directories and mostly word of mouth recommendation. So my site is basically a place I send people to, rather than they find automatically, and they just want to hear music show reels when they get there. So, apart from a couple of bits no one reads, that is what it is dedicated to. Hence the loud noises available on the home page
    1 point
  26. From an SEO standpoint, I think it's clear that you'd be making some compromises by putting everything on one page. It means less-specific pages in terms of content, so less likely to match specific keywords. But for a site that really benefits from being on one page, maybe those benefits outweigh the SEO aspect. I think that the more you focus on catering to what is right for your audience and content, the less SEO even matters. If you put up something that's going to drive quality incoming links, the value of those links is going to carry more weight than anything you compromised in structure. But seems like it'd be possible to also do it without compromises as well. You could build it as a multi-page site and then have the single-page nature derive from javascript ajax calls. Meaning, if you visit on a JS-capable browser, you get the progressively-enhanced version. If you visit on a non-JS browser, you get the multi-page version. Just so Google doesn't think you are trying to do some JS monkey business (if they can even tell?), you'd probably still want to make the multi-page version accessible to the enhanced version, perhaps via footer nav or sitemap link.
    1 point
  27. I would say: "ProcessWire Deutschland" or "ProcessWire auf Deutsch" @Joss: would be ProcessWire DE not FDR
    1 point
  28. Ryan, for a completely different reason, that was a really useful little tutorial!
    1 point
  29. Thanks Soma, I've brought this in and just testing locally so it should be in the dev branch very soon.
    1 point
  30. 1. More complex validation can be done without fixing PHP code? (something like only alphabetical text allowed before the dot and only numbers are allowed after the dot) There's html5 input field patterns validation coming in 2.3 or it's already there if you use current dev. Field setup under "input" tab "Pattern". 2. Make the field set as unique so that no duplication values are not allowed? There's a double no in that sentence. So I guess you didn't mean it. There's no support for this by now. But you can easily hook the page save and add your own validation and checks. 3. two or more fields are related to each other and make them as one field? Not sure what that means. But maybe this is what you're looking for. http://modules.processwire.com/modules/fieldtype-concat/ 4. A field can be filled automatically such as 'last logged in time', 'user index number', 'posting numbers', and so on. Again not sure what you mean by automaticly filled. It's all possible through hooks. It also depends a lot what you're trying to do. If you build frontend users, or just for backend. For frontend you would build the user profile and all it's handling yourself anyway so it's all possible and only your imagination and skills is the limit. It's like giving someone a toolbox and ask can you build a wooden box?
    1 point
  31. Hi, Hopefully if I understand you correctly, you are looking for a way to have truly responsive images that resize to any screen size? I use this: img { height: auto; max-width: 100%; width: auto; } In your html for the <img> omit the width and height attributes and you should end up with something like in these examples below. Just resize your browser. Example 1 Responsive images (in progress, so temporary link) Example 2 Responsive slideshow I hope I have not misunderstood your intentions?
    1 point
  32. Nico, could we have a small example but done from creating them in code to end user, using them in a textarea? This looks great but I can't get my head around exactly how to implement them! Thanks!
    1 point
  33. This looks like a great module Wanze! I have a suggestion: It would be great to be able to click on the title of a page and open that page for editing in a lightbox overlay not sure how easy this is though. I can see a great use for this as a quick SEO overview as the title, name (url) and parent (parent url) are shown. Further to that - it would be great to be able to have this available with reduced privileges for roles less than the superuser (with just the ability to see the list and perform actions applicable to their selected roles).
    1 point
  34. Hi Onjegolders Yes, it is one of the things that has frustrated me enormously, particularly in recent years. I know search engine optimisation is important, but so are returning visitors. So much emphasis is now put on hitting keywords that sites are often uncomfortable to read, products described badly, and there is a complete lack of one-to-one communication. Websites, like radio, are only talking to one visitor at a time; there is not a crowd of people looking at the website, there is lots of one persons. Well, with any luck, you will get a client that says, "I want my site to sound like me," and are happy to pay for that. Then you can give me a call with pleasure. Good luck mate.
    1 point
  35. (¯ `v´ ¯) `·.¸.·´ ¸.·´¸.·¨) ¸.·¨) (¸.·´ (¸.·´ (¸.·¨¯` PWLOVE
    1 point
  36. I suppose Pete, myself and the other Britons should start working on the British version of the site. It will be particularly genteel. be full of really obscure references to concepts like "colour" and "through" and take tea breaks between pages...
    1 point
  37. @ryan: I tried this out a little (by adding support for this to the SelectorTest ) and it seems to be working, well, almost perfectly. When trying to get 'modified' property, the 'created' timestamp is returned instead. They do differ in the database though. Another thing (this could be considered a feature even): when adding a new file, both properties get their values set to the time of the upload, not the time the page is saved. This doesn't really matter, but if you add a new file and write a description for it as well before saving the page, 'modified' property will be set according to the page save leaving the properties with different values although the user might consider having done one single transaction.
    1 point
  38. C'mon be honest and confess that it actually took you 6 minutes
    1 point
  39. Should be. It's not responsive currently but I think that shouldn't be a problem. It's working in IE, too
    1 point
  40. Soma, you're the best.....
    1 point
  41. Teppo, thanks, now it works. It doesn't work on master though: If using master branch, I do get icon but don't see the hover. Instead of JS error: Uncaught TypeError: Object [object Object] has no method 'on' Above is probably because of jQuery version. I think it is just fine to create modules like this just for latest and greatest in mind, so focusing on 2.3 should be fine. So you can forget me about even mentioning this. Now that I got it working... just WOW! Absolutely brilliant solution and implementation. Congratulations on this Teppo and big thanks for your work on this. Very solid and very nice work! I just used 10 min of my life just clicking and watching that nice flashing animation with big smile on my face. I think this should definitely be on core. Not installed by default, but definitely ship with core. And maybe pack in with upcoming 2.3 (I think it can easily wait week or two to get this beauty in). And now that we have this "proof of concept" (I also think this is much more than that) - I really like the field level of version control. Makes a much more sense than page level version control. Thanks Ryan to that UI mockup btw, it was spot on!
    1 point
  42. Updated czech localization pack (contain 85 files). Current version: 0.9.2 pw_czech_092.zip
    1 point
  43. Probably yeah. Seems that I was actually having same problem as Antti. Thanks for noticing this, there's a fixed version at GitHub now
    1 point
  44. Ryan: thanks for your feedback! As soon as I get some free time for this, I'm going to start making some improvements - judging on your comments and my own thoughts they're going to be mostly about scalability (both in terms of both UI and data.) Main reason for this would be somewhat more manageable (and scalable) data structure. Currently metadata is saved to one table, content to another - which in larger use could result in very large (and thus pretty slow) content table. By using individual files instead of this table might result in better scalability.. though flat file hierarchy probably wouldn't be such a good idea either, since it could result in disk-related bottlenecks in the long run. Another idea would be to just split that content table into smaller chunks. One table for each field, or perhaps each fieldtype? I'll have to take a bit closer look at this one. I'm not even sure if it's really such a huge problem or if I'm just overcomplicating things. What do you think? Probably something similar to what I'm doing with (both) history modules would make sense here too; let the user define this via module settings. Like Joss pointed out, some sites might want to hold on to their data "forever", though I'd like to suggest that abacking things up properly might make more sense in those cases. On the other hand, on many occasions data older than, say, 6 months to a year, wouldn't be of much use to anyone. (Another CMS I've been using stores similar data for approximately 6 months in "easy to get" format, which has been more than enough in 99% of cases.) I guess you're right. It's just that I saw somewhere a nice demo of this and thought it might be really fun to have. Let's see This is a very good point and something I'm going to focus on. Short answer is that it scales "relatively well" at the moment; UI wise this is handled by max-height + overflow-y: auto, but all revisions are loaded and processed when page edit is opened. It could definitely use some extra measures for large amounts of stored revisions, probably something similar to what you've described here. This is very much related to some of the things I mentioned earlier in this post. Removing individual rows might make sense in some cases, but most that's not very high on my list here. I'm definitely going to add a configurable time limit, but would also like a quantity limit (like you're describing here.) If I recall correctly latter was also suggested by Nik and now I've got double the incentive to make it happen
    1 point
  45. Ryan, you're right. My mistake in template settings. It's all ok so far. Thank you for v e r y fast reply!
    1 point
  46. Wow. I did not expect this much response. I think it says a lot for the community and the passion behind Pw. As I mentioned, I am very new to Pw so it is possible that once I get to know it better I will agree that a template language is completely unnecessary. Also, I have no problems with it being a module that can be loaded if needed. I certainly don't think it needs to be in the core. So, if there are modules that already exist then I am satisfied. For example, I hate TinyMCE is totally screws up my code. So, I don't use it, but it is there for those that want to. That is one of the things that I see with Pw that I like. Thanks for all the feedback and comments! Now, for my own enlightenment, I am interested in where you all draw the line between Design and Development. In my current situation, my designer knows HTML and CSS (he obviously knows design too). So, in my thinking, that is the demarkation point. I should not need a copy of Photoshop to develop and he should not need to load debugging tools, etc to design. He provides clean HTML/CSS and I fill the templates with data. That is why I feel it is important that the designer can modify the templates and not just hand them off to me to implement. The user is expected to handle the data so why are we keeping the designer away? Is this not a 3-way partnership? I know that some of you are one-man shops and totally capable of doing it all, but I am trying to understand this from a small team perspective. I have done the last few sites in MODX Revolution and the designer was fine with being able to modify the templates and leave all PHP to me. If he needed something specific, he could ask and the same for me. The user just entered the content. It seemed to work well and balance out the work. My musings... I will probably look back on this message and laugh at my Pw naivety. It's all good and thanks again for being so responsive and open. Anthony
    1 point
  47. ProcessWire is actually the first iteration of this CMS that doesn't rely on a template engine. And Dictator CMS (the grandaddy of ProcessWire) was entirely template engine based, with no PHP API or PHP support at all. I'm no stranger to template engines. While there are benefits to template engines, my own experience has been that the benefits are largely perceived rather than experienced. There are also some tangible benefits too. But how many of those tangible benefits apply varies greatly from system to system. ProcessWire has a nice API, but most CMSs do not. For many of those CMSs, the template engine is what makes the system accessible (or at least, more accessible). Expression Engine is an example. In those systems, template engines are providing a huge benefit by isolating the developer from having to use a complex or crappy API. Nobody would use these systems without the template engine. But in a system like ProcessWire, a template engine is redundant, less capable, and ultimately more complex layer of overhead. Most of the time, we do not want that kind of extra overhead in ProcessWire. In our context, the only real benefits of a template engine are if you have some kind of syntax preferences (PHP is not always the prettiest syntax) or if you want to have a jail. There are some valid reasons to have a jail, as pointed out earlier… but I prefer education to jail. Still, I understand the reasoning and can't say it's always wrong. Just that it's wrong for a core default. There's also that benefit of perception. If one perceives there are some other benefits to a template engine, they will seek out systems that have them, even if perception isn't always reality. I believe strongly in the benefits of our current approach and API. I feel these benefits are far greater than what comes from any template engine. And I've discussed them at length many times in many places, so I won't rehash that all here. But I've always wanted ProcessWire to support template engines, just not to require one. So I like what I see with the Twig and Smarty modules. Actually, the Smarty module seems like it would be especially simple to work with, since it bolts in so quickly and easily. I hope to see more in this area and am always willing to do whatever it takes to support add-on template engines (we even added a hook or two to support the Twig module). While I personally don't need these template engines and sometimes question their value, I also very much support them in ProcessWire as modules. Perception is powerful, and we're trying to grow our audience. Likewise, there may be some that have template engine preferences beyond just perception. Anything that opens a door for more people is a good thing. While ProcessWire's core isn't and won't be built around a template engine dependency, we fully support use and implementation of them as modules. And I'm also willing to add any new core hooks or capabilities necessary to support the development of such modules.
    1 point
  48. echo $pages->get("myrepeater.field2=bar")->myrepeater->get("field2=bar")->field1; we should make a compilation of soma's one-liners to rival with this https://www.youtube.com/watch?v=GeeyWvo1rNg
    1 point
  49. I think we should do it the WordPress way (sorry for mention the w-name). We don't need processwire.de - we just could use http://de.processwire.org/ (or .com) as a beginning (like: http://de.wordpress.org/). This page doesn't have to include all of the pages processwire.com does. It just would be a "hello german user. Yes, ProcessWire has a german admin interface. You can downlad the bundle here." And if you download processwire on this site it may should contain a german profile already...
    1 point
×
×
  • Create New...