Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/23/2013 in all areas

  1. I think Ryan means this: $pages = wire('pages')->find("template=property"); foreach ($pages as $page) { $page->images->deleteAll(); $page->save(); $page->images->add("http://images.com/image1.jpg"); $page->save(); }
    2 points
  2. thanks martin/SiNNuT for posting on pure; i was thinking of trying to build something with this soon: http://www.getuikit.com/
    2 points
  3. http://processwire.com/talk/topic/3740-yahoo-css-library-httppurecssio/ All joking aside, this is a pretty neat resource and the soon to be released version has a more robust grid implementation. They do say so on the site, but keep in mind aforementioned file sizes are gzipped. Uncompressed it's more like 19 or 20 KB (still small though). Another one i'm trying out atm is http://cardinalcss.com/
    2 points
  4. Just stumbled on this http://scrollback.io/. Could be a nice solution to bring the IRC channel to the forum.
    2 points
  5. I wish there was support for progressive JPEG. To control it, set it in the imageSizerOptions array.
    1 point
  6. Hi Guys, I'd like to share a module the development team at metric marketing and I came up with. I have a lot of experience with the Symfony framework, and when working with PW I came to miss some of the practices I grew accustomed to when working with PW. This module is aimed at bridging my previous experience with doing things to PW way. I have a big readme on the github project so be sure to check that out to get all the details: https://github.com/jdart/Spex From the readme "The project makes use of lessphp, less.js, jQuery, modernizr, Minify and the ProcessWire Minify Module." There's an example site in the github repo that illustrates how Spex works: https://github.com/jdart/Spex/tree/master/example-site In short your template file isn't responsible for including the head and foot etc... and instead is injected into a layout. In addition to this is adds some conventions for adding css/less/js to the page so that it can be combined and minified. Have a look through it and let me know if you have any feedback.
    1 point
  7. Last week I found a CSS framework called pure. Although there are plenty of good CSS framework out there, but sometimes those frameworks have just to much. Pure on the other hand is a small collection of css files. I like this approach, think I gonna use it in the next project. Base 1.2KB, Grids 0.9KB, Forms 1.4KB, Buttons 0.8KB, Tables 0.5KB, Menus 1.2KB Take a look: PURE
    1 point
  8. Here is another thread where we talked about frameworks. If size and flexibility matters, PocketGrid could be a good choice? It's only a grid, nothing more. Very minimal and seems to be very flexible. Looks like you can do anything with it (like doing with PW). But haven't tested it.
    1 point
  9. After a lot of research I've found the solution, which is to make the Silex session handler wrap the existing session handler. So far, so good!
    1 point
  10. These are tools for local webdevelopment, including all you need. Easy to handle. Also there are portable versions (no need for installation). http://www.apachefriends.org/en/xampp.html http://www.wampserver.com/en/ http://www.easyphp.org/
    1 point
  11. Yep, seems to work like you described Soma here as well. This is what I'm seeing: when a repeater field "xx" is added to a template "yy", no data is written into field_xx for pages with template "yy". And because selector "zz.count" relies on column "count" in field_xx, the selector doesn't work. But when such a page is saved the next time, a row with proper "count" value is written into field_xx and the selector works as expected. I guess those rows should be written for all pre-existing pages of the template when a repeater is added. Either that or some more SQL to cover the non-existing rows when <repeater>.count is used.
    1 point
  12. Testing further: Deinstalled Language Support to rule that out. Now I found out: The repeater.count=0 only works for pages that are once saved after the repeater is added to the template. So to say it different: For pages that are not yet saved, once after the repeater was added to the template, it doesn't find them.
    1 point
  13. While this technic is nice to know it is much easier to enable compression via .htaccess, also because of the reason Ryan mentions. I don't see any reason why to do this via PHP. See the H5BP htaccess for nice technic https://github.com/h5bp/html5-boilerplate/blob/master/.htaccess#L379 and other goodies. Also only while the html served might be 4kb instead of 24kb, this doesn't make the page load that much faster, but using this for all resources along with caching headers you get a ~30% decrease of file sizes. Using PW template cache can have the most impact on page loading, depending on how render intensive the page is, you get a loading time around factor 2-5 times faster just because it doesn't need to render it.
    1 point
  14. There is a bug in Page.php Easy fix though: http://processwire.com/talk/topic/4141-foundation-template-problem-in-top-nav-bar/
    1 point
  15. @daniel.s, this is not a good case to use repeaters as the number can grow to the point of not being practical at all. Pages is the way to go. @BeardedCanadian (great name ) the way around the two step page creation is to create a new system for making these new pages. You can easily create new pages with the API http://processwire.com/talk/topic/352-creating-pages-via-api/. So, the only thing you need is to a new page where you put a form with the needed fields for your thoughts/quotes/links and use the API to create the pages instantly. If you want these pages in the admin, have a look at my Admin Custom Pages module http://modules.processwire.com/modules/process-admin-custom-pages/. edit: and welcome to the forums both of you!
    1 point
  16. Limiting by IP or cookie both have their drawbacks. You can imagine an office with 100 workers all behind one ip address. Cookies can also be deleted. For my needs the implementation is good enough, but if you really wanted to prevent bots taking advantage you'd require users to be logged in to vote. That being said the voted detection could be a lot more sophisticated.
    1 point
  17. I would set something like this: Create template called babysite. Give it all the fields you need. Then create /templates/babysite.php It would be something like this: <?php $pathToTemplate = $config->paths->templates . "babysites/" . $page->name . "/index.php"; // If babysite index.php exists, we include it, otherwise we include default or throw an error if (file_exist($pathToTemplate)) include($pathToTemplate); else throw new WireException("TemplateFile couldn't be found"); This assumes you keep your babysites at /site/templates/babysites/babysitename/index.php That is good folder to keep babysite assets too, but of course you can get those from everywhere. You could of course take this much further. But if babysites doesn't share much together (like some basic structure), then I think this would be simplest and most straightforward way to go.
    1 point
  18. Mary, Bear in mind though that 1 template = same fields for each baby site. That will not be your situation, I think, since some sites will have fields that others do not have, no? So, you will have several templates, just not thousands! since there will be commonalities. What Antti (=Apeisa ) is describing is essentially what Soma illustrated in the thread I linked to This is a basic example, and there could be better ways of doing this. Each baby site structure, i.e. the HTML could be added to a .inc file that will be included by PHP to your template file, depending on the page being viewed. The .inc file will also have PHP, especialy PW API in order to output the baby site page's fields. In this .inc file, you may wish to only includethose fields that are unique to a baby site. For instance, all baby sites will have a "title" field. No need to incude that in the .inc file. Instead, include that in a "main.php" as Soma described. Key question is, how do you load the correct .inc file for each baby site? Assuming you have a site structure as follows: Home About Services Baby1 Baby1-Child1 Baby1-G.Child1 Baby1-G.Child2 Baby1-G.Child3 Baby1-G.Child4 Baby1-G.Child5 Baby1-Child2 Baby1-Child3 Baby2 Baby2-Child1 Baby2-Child2 Baby2-Child3 Baby2-Child4 Baby3 Baby3-Child1 Baby3-Child1 Etc.. In order to select any of the above pages in the PW tree, you have several matching criteria on hand. You can select pages based on their parents, IDs, templates, etc. In our case, we want to make this simple. We want a selector that will match each unique Baby site including its children, grandchildren, greatgrandchildren, greatgreatcgrandchildren, etc. That selector can be the $rootParent. This is the "ultimate" parent closest to the "Home" page (i.e. closest to page->id=1). Hence, the rootParent of "Baby1-G.Child5" is "Baby1". The rootParent of "Baby2-Child4" is "Baby2" and the rootParent of "Baby2" is itself, i.e. "Baby2", etc. Armed with this, using the delegate approach, we can include the correct .inc file for each Baby site by giving them unique names. E.g., the .inc file for Baby3 would be, you guessed it, "Baby3.inc". You may choose to name it using the actual name of the Baby Site, .e.g "baby-3.inc" (note: lowercase and hyphen; i.e. PW page naming). Same, for others, e.g. "baby-1.inc". In your "main.php" you would load the correct .inc file as follows, for example: include($config->paths->templates . "views/{$page->rootParent->name}.inc"); This assumes that you have a folder called "views" within your /site/templates/ folders. In the case of Baby1 and its descendants, when viewing those pages, PHP would load the file "baby-1.inc". Inside this file would be, for example the inner markup of the site Baby1. Of course, this assumes main.php will have the rest of the markup, e.g. the header and footer stuff. This also does not directly answer the question, what if there are variations in the Baby site's pages themselves? I.e. the "main page" of e.g. Baby1 could be structurally different from Baby1-Child1. This complicates matters but you can deal with such variations in the .inc file itself since each of your Baby sites will not have that many pages, no? This is a very basic example. It boils down to how you will organise your site. I have not tested this approach for speed/performance but so far, it has worked well for me. There are other alternatives for loading the correct HMTL, as you would have seen in the Soma thread + others not mentioned in that thread. Important to note is this: PW does not prescribe any method over the other. It boils down to your preferences and sensibilties As for CSS, this is one way of loading CSS files: <link rel="stylesheet" href="<?php echo $config->urls->templates?>css/style.css" type="text/css" media="all"> You can easily apply the same logic of the .inc file here. E.g., by having a CSS file called baby-1.css that will be dynamically loaded when viewing Baby1 pages (i.e. replace the "style" with {$page->rootParent->name}.css, for instance. Hope this helps. Like I said, it is just but one example. Others will have other views but this should give you an idea....
    1 point
  19. Hi everyone, I made a walkthrough of a web app I built using ProcessWire for the Tenova Group mining company. They needed an intranet application to keep track of their daily plant operations. I designed and developed a ProcessWire solution that would allow registered employees at Tenova HYL to record events regularly in an event log. Storing all of the events in this manner would allow registered users to find the events they're looking for using keyword search, date filters as well as filters based on other criteria. Each event also allows the user to upload supporting files for download, such as Word documents and PDFs, as well as upload relevant images to be displayed in a modal window. A high-performing, powerful solution using the ProcessWire CMS. Read about the project here in my portfolio. See the video here: Tina Holly tinaciousdesign.com
    1 point
  20. You're awesome! This worked: if(!$error) { $subject = "Kontakt formulär"; $message = ''; $headers = 'From:'.$form[epost]."\r\n".'Content-Type: text/plain; charset=utf-8'."\r\n"; foreach($form as $key => $value) $message .= "$key: $value\n"; mail($emailTo, '=?UTF-8?B?'.base64_encode($subject).'?=', $message, $headers); $sent = true; } Thank you!
    1 point
  21. I've forked the module and added javascript callback. Now I'm working on the PUT and POST methodes then we have a complete restful solution. But does anyone know if it's possible the call the input settings of a field ? Like required, pattern, ... for a field
    1 point
  22. A newly released CSS library from the folks at Yahoo!: http://purecss.io/ There already are a gazillion out there but this does seem like a pretty neat CSS baseline for some projects.
    1 point
×
×
  • Create New...