Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/15/2013 in all areas

  1. welcome.mr kongdondo have no.avotor u do so one i make for u sarah yours i make next
    3 points
  2. Just added this module to the modules directory. http://modules.processwire.com/modules/chrome-php-logger/
    3 points
  3. Yes, something like that. I'd put it this way: When using tables in another database, PW selectors can't help you so just use plain SQL. If you like, you can use PW's Database class for connecting, some escaping and debug timers, but other means of getting there are ok too. When using data from pages in PW, use PW selectors and you'll get most likely the best performance with all the tricky things like grants taken care of.If the selector engine can't offer what you need, you're still able to use plain SQL. But go down that road only if you really need to and preferably know what you're doing .
    3 points
  4. Soma is owed so many kegs of beer by the folks he's helped — he can afford to give some away.
    2 points
  5. PS: things are already simple - nothing wrong with making them simpler though, especially when it's no additional work or overhead for those using the module and working with an IDE. For me, personally, having full IDE support for any piece of PHP software has become a sign of high quality - it means everything can be validated automatically, which usually means it has been. You can't expect a person to do the same for 10,000 lines of code on every release. And vice versa, if a computer can't infer the meaning of your code, how can you expect a person to? Whether you have IDE support for the users who use an IDE or not, having IDE support means you have automatic safeguards and checks that cannot be performed by a person.
    2 points
  6. You only have a handful of Page objects and Fields? I think you misunderstood - this does not provide IDE support for ProcessWire (which still needs a lot of work in this area) but for your templates and fields. I'm sure you have more than a handful on complex sites, and I'm prertty sure they're not always the same? It's not about simple or difficult, it's about proofing your work - knowing in advance if you misspelled a property-name, or not having to go back to find the name of a property on an admin-screen, it saves time. With inspections in PhpStorm, there is also the added benefit of being able to automatically find errors - if you have dozens of templates and you have to make a change like renaming or deleting a field, automatic inspections will instantly reveal which templates are affected. Most of my day-to-day work is not little projects, but large complicated business-systems - while I used to be able to keep it all in my head, I'm not getting any younger. A good IDE will help you stay fast and accurate when you grow older, wait and see
    2 points
  7. @kongondo: It looks like you're trying to implement something that's in core already. Take a look at http://processwire.com/api/selectors/, especially "Limiting the number of results returned by a selector". There's a description of limit, start and even end, should you ever need it. In short: enable page numbers for your template and use only limit without start in your selector. You can get the total number or rows matched from $values->getTotal() and even render a pager using $values->renderPager() if you like.
    2 points
  8. Hi All, Thanks for your tips. It got my brain working again and I (gasp) *Googled* for the answer. Which I should have done in the beginning. Google is our friend. Well, sort of. I found this tinyMCE directive, added it, and it worked like a charm: apply_source_formatting:true Thanks! Peter
    2 points
  9. Hello kongondo & welcome to the PW forum. Whilst I agree that Ryan's produced an amazing product in ProcessWire I think it goes beyond just the software. Of the CMS devs I've been involved with Ryan's the one project lead who has been the most open, from first contact, to meaningful contributions towards the site, docs, forum and code. Some others have been open, most friendly, but none to the same degree. Consequently he's attracted a welcoming, talented & professional group of people to the project and I've learned a lot from being involved here.
    2 points
  10. Fredi is friendly frontend editor for ProcessWire. Code and documentation: https://github.com/apeisa/Fredi Module page: http://modules.processwire.com/modules/fredi/
    1 point
  11. Chrome Php Logger Module to log useful details directly in your Chrome JS console. You can inspect most as objects and see infos or values. To enable logging with this module you have to enable debug modue in config.php. If debug is set to false in config.php, it will not output any log. Important: It is not recommended to enable it on live stage, as it reveal infos you might not want everybody to see, although it's not obvious as it requires the ChromePhp Extension installed and enabled. - render time - memory consumption - cpu usage - current user infos - current user roles - current user permissions - current page with all its fields and their value and field settings - page cache/loaded on request count - fuel - modules loaded - Server vars etc. - Cookies - Requests - mySQL query log When installed you can also use ChromePhp static methods to output your own data in all your templates or modules: ChromePhp::log($page->somefield); Note: This module requires the ChromePhp Extension installed to see the log in the Javascript console. More infos can be found on http://chromephp.com Download: Modules Directory: http://modules.processwire.com/modules/chrome-php-logger/ Github: https://github.com/s...ChromePhpLogger
    1 point
  12. Hi, I'm not sure if this is an API question but here goes. On a few recent sites I find myself creating the same sets of fields over and over - for a 'settings' page for example. Is there a way I can import/create a group of fields quickly? If you haven't seem Ryan's Form Builder there's a nifty import/export tool. That's what got me thinking about this. Cheers Marty
    1 point
  13. Not sure if any of you US guys are in Boston but hope everyone's OK. Crazy world.
    1 point
  14. Not good... hope everyone is okay. Fckng unbeliveable :-/
    1 point
  15. Love the text on your site kongondo.
    1 point
  16. LOVE the marketing Soma.
    1 point
  17. Well said Tom, my IRC access is borked :/ Need to fix.
    1 point
  18. Sorry I haven't been able to reply for a long time. I recently moved and then caught a horrible cold that really dragged me down. Could someone help me get the PageList working without Javascript?
    1 point
  19. Ok once again I have beaten myself... after trying to find a reason, nothing worked I thought it just can't be and knew there must be something stupid like $page->template = "home" in the code... and gotcha! I really should be more careful and always use "home" == $page->template Thanks diogo for your time.
    1 point
  20. Just tested this on a new 2.3 install and everything worked normally. Just in case I didn't understand what you mean, this is what I did: went to basic-page template and changed "alternate template filename" to sitemap. Now I have a sitemap in all pages.
    1 point
  21. I'm not really sure I get what you're trying to do here and what's wrong, but isn't this essentially what you're describing there: $start = 0; $limit = 15; $values = $pages->find("parent=/, start=$start, limit=$limit") If you need total count of possible results (without limit) you could always use $pages->count() to do that separately: $total = $pages->count("parent=/"); // or like @nik pointed out below: $total = $values->getTotal();
    1 point
  22. @jsantari Wirebox is indeed intended for use in the backend only as a replacement for Fancybox, for the frontend you can use any lightbox that you prefer. @diogo I'll add this to documentation so it would be clear to new users.
    1 point
  23. Quick and dirty solution would be to had this line to your admin-theme: $(".Inputfield_repeater .ui-sortable > li").addClass("InputfieldStateCollapsed"); you could add it in the end of the main.js file for instance $(document).ready(function() { ProcessWireAdminTheme.init(); // very dirty hack to collapse the repeaters, make something nicer later $(".Inputfield_repeater .ui-sortable > li").addClass("InputfieldStateCollapsed"); });
    1 point
  24. Thanks Luis. - so have to say: I only want put together the basic stuff but also want to keep it modular and scalable. For example I personally only use mp3-files but if people use other formats like ogg they should be able to extend the class module for that easily. Maybe with some help it could become really nice and not only poor basic ;-) If someone has good skills on how to build / design / layout admin pages with that UI-stuff it would be really helpful if he/she could design the output for the backend. Also if someone is good with frontend design and want to collaborate that would be great too. I have a really short screencast of what I have done till now, (most of this was learning how to send green or red messages to admin screen, how / where to store config data, to create permissions and roles, and basically how to create a module that has a page in the admin section, ...): https://youtu.be/u_S8ajLkzRI Next steps are to parse ID3Tags, compare file-data with DB-data and import new tracks. Question: is it possible to store arrays or WireData on a page?
    1 point
  25. I like your idea and different people here actually customise the manager to suit their preferences/needs. However, I think this is one of those things that is left to the user to decide so that PW doesn't box you into any design. In fact, the default installation is just a demo page. In your case, you have need for a "maintain" section. Not everybody does. The beauty with PW is one can do what they wish with the manager as with everything else. Have a look at the different admin themes available for download here and you'll see what I mean. . One can even decide not to have a manager at all and PW will still run
    1 point
  26. Adrian, nothing like that. I have been super happy with all the great feedback and ideas you have gave. Keep em coming! I played with renderAll little more and not entirely sure if it really fits... Gotta get some real life experiences before deciding.
    1 point
  27. Hi Grays, welcome to the forum. Even though I have been playing with PW for a couple months now, I too am still very green and new to it. I was in the same boat as you and still am trying to grasp the basics, but take the advice of everyone else above. The people here on the forums are very helpful and friendly. Don't be afraid to ask questions. There are a lot of smart peeps here and I find this is one of the most friendliest, most responsive CMS forums of them all. Make friends with other newbies (such as myself) and follow the questions they ask. Seach the forums for the ones asking basic questions and those will more likely be the newbies. I think for me, the best thing I could do was to take it slow and lower my expectations. I fell in love with PW right off the bat and wanted to be a a pro in it. But, even though I had read a few PHP books and took some courses beforehand, in reality I was lost and dissapointed. It's more a mental/confidence thing with me, but once I accepted the fact that it was going to take some time, and I wasn't going to be an immediate whiz, things got easier. So. I started off (still am) doing the basics, one thing at a time. Break up your site into smaller parts and work on each one by one. When you get something simple working, your pride will fuel the next challenge and before you know it, you'll be at the top. Analyze the code here in the forums and don't just copy/paste. Try to really understand it by cross checking with how PHP works. A great thread started not long ago on learning PHP is here. You may not understand it in one try, I know I didn't. Sometimes it takes days or weeks for something to "click" in your head. Read, re-read, read again. Things DO get easier but it takes time, and time is the secret. Practice helps. It's inspiring what you can do with PW and what keeps me going is knowing this is the best CMS out there. I have researched and tried almost all of them over the years, but nothing compares to PW. I am inspired every day to continue learning and not giving up because it's absolutely worth it. MY breakdown to how I am learning: Take it slow. Break code examples down line by line. Moving on to the next line only after knowing what each before it does. You'll get it! Don't attempt something expecting results the first time. Take pride in humiliation. You can only learn after making mistakes. Read this PW wiki Study Codecademy PHP course along with a couple PHP books. Try to go through every forum completly. Go through each page one by one, bookmarking where you left off. I do this before I go to bed. Before you know it, you'll have read all the forum topics and can know be updated when new threads post. ask questions. I know this can be kinda hard because you don't want to look like an "insert insult", but the truth of the matter is if everyone is afraid to ask then it's hard for newbies like you and I to find answers to basic questions. It's a win win for everyone and the CMS itself. breaking down basic elements of a site one section at a time and searching the forums for how to do it (navigation, multi-level navigation, photo gallery, forms, etc..) You may have to read multiple threads but it's all there. Good luck and don't give up! I can never look back at any other CMS, even during times when I'm frustrated or lost! I only get frustrated with PW because I do not know YET how to proficient. I was frustrated USING other CMS's because of how they were built and I knew their code. Says a lot right there.
    1 point
  28. I'm assuming the 404 you are getting is an Apache one rather than a ProcessWire one. You are seeing mod_security in action. When mod_security gets in the way of legitimate content management, then it's configured in an overly agressive manner. I would ask your host to loosen things up a bit, or if they can't, have them disable mod_security for your account.
    1 point
  29. Looks like you are on the right track there. As for the field name and/or id, I'm guessing you don't want to use the title though. In order to make sure you've got something unique, you might want to use "myfield{$cat->id}" or something like that. If you don't need to support images/files in repeaters, then it won't be too difficult. You would add one or more repeater items at the end, but make them hidden or collapsed. You could have a little javascript link that says "add item" and when clicked, it unhides the next one. Make the fields in each follow a different name format, like "myfield_new1" for the first one, "myfield_new2" for the second one, etc. Basically, some name format that your processor would know is referring to a new item it should add. Then it could process them like this: $n = 1; $name = "myfield_new$n"; while($input->post->$name) { $item = $mypage->myrepeater->getNewItem() // populate any fields in the repeater you want $item->title = $input->post->$name; $item->save(); $mypage->myrepeater->add($item); $n++; $name = "myfield_new$n"; } if($n > 1) $mypage->save('myrepeater');
    1 point
  30. I've been making regular updates on the dev branch to the LanguageSupportPageNames module, so if you guys are using this, you may want to keep track of the updates. The good news is that this module is now running a production site: http://tripsite.com/cruises/ (only the /cruises/ site, as the rest of the site is running on a different copy of PW). This morning I pushed an update that makes it easier to tell if a given $page is viewable in another language. Now you can do this: if($page->viewable($language)) { ... } // Language object if($page->viewable('es')) { ... } // Language name That is basically telling you if the page has its "active" checkbox checked. Since these pages would already be excluded from search results, you don't typically need to use it except when on a given page and trying to determine what other languages that page is available in (like if you want to link to them, as the select box at the top of tripsite does).
    1 point
  31. When you get into sending POST data, ProcessWire has an http class that you can use rather than something like CURL. The benefit of using PW's WireHttp class is that it will fallback to sockets if it has to, ensuring the class works just about everywhere. Here's an example of the same web service we outlined above, except that this one posts to it: $data = array( 'username' => 'ryan', 'pass' => 'mypass', 'email' => 'info@grab.pw' ); $http = new WireHttp(); $result = $http->post('http://www.domain.com/path/to/service/', $data); if($result) { $result = json_decode($result, true); if($result['status'] == 'success') echo "Success! $result[message]"; else echo "Error! $result[message]"; } else { echo "error posting data"; } As a side note, this service is using the same password for the user to add, and the web service password. In reality, you'd probably want those to be different things.
    1 point
  32. Glad to hear this. We have so many here that are part of the MODX community too that it seems like a family, and I really want to see MODX do well.
    1 point
  33. If you have a robots.txt, I would use it to specify what directories you want to exclude, not include. In a default ProcessWire installation, you do not need to have a robots.txt at all. It doesn't open up anything to crawlers that isn't public. You don't need to exclude your admin URL because the admin templates already have a robots meta tag telling them to go away. In fact, you usually wouldn't want to have your admin URL in a robots file because that would be revealing something about your site that you may not want people to know. The information in robots.txt IS public and accessible to all. So use a robots.txt only if you have specific things you need to exclude for one reason or another. And consider whether your security might benefit more from a robots <meta> tag in those places instead. As for telling crawlers what to include: just use a good link structure. So long as crawlers can traverse it, you are good. A sitemap.xml might help things along too in some cases, but it's not technically necessary. In most cases, I don't think it matters to the big picture. I don't use a sitemap.xml unless a client specifically asks for it. It's never made any difference one way or the other. Though others may have a different experience.
    1 point
  34. I always put these kind of things into the home template. If there are a lot of fields for a header or footer that I want a client to manage I stick them in a /FieldsetTabOpen/close set. So you end up with tabs in the home page edit screen with something like this: Content | Header | Footer | Children | Settings | View
    1 point
  35. Welcome aboard, For your safety, please take a moment to listen to this important message about safety on board. In preparation for departure, fasten your seat belt by placing the metal fitting into the buckle. For your comfort and safety, adjust the strap so it fits low and tight around your hips. To release your seat belt just lift the face plate of the buckle. As you know, turbulence is sometimes unexpected so we advise you to take a look at Somas Cheatsheet, you will find a copy under your seat (http://processwire.com/api/cheatsheet/) On behalf of all of us, we wish you a very pleasant flight. Thank you, for choosing ProcessWire.
    1 point
  36. To make it even shorter, you can also do this (specify path to category): $posts = $pages->find("parent=/posts/, category=/category/events/"); Or this (specify title of category): $posts = $pages->find("parent=/posts/, category.title=Events"); To take it further, you could replace "title" above with any field present on the category template and match based on that. But I think 'title' or 'name' are probably the most common ones. If your 'category' field only exists on your posts, then technically, you could leave out the "parent=" part. Though a more specific selector tends to scale better than a less specific one (like if you re-use your category field in another template). So I do think it's worthwhile to keep it, or use $pages->get('/posts/')->children('...') like in your example. In PW 2.3 (dev branch), you can now do this as well, which would be the shortest possible alternative: $posts = $pages->find("category=events"); The above is matching the page's name field. Since there is no slash in the value "events", it assumes you are talking about the page's name rather than path or ID.
    1 point
  37. Ryan, Thanks this gave me a great place to start. I thought I'd share the version I created in case anyone finds it useful. • Single template for the login/logout. • Automatically redirects the user back to whatever page they originally requested after they login. ./includes/login.php <?php // Handle logouts if($input->get->logout == 1) { $session->logout(); $session->redirect($page->path); } // If they aren't logged in, then show the login form if(!$user->isLoggedin()){ // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($page->path); } else { $session->login_error = 'Login Failed. Please try again, or use the forgot password link below.'; } } ?> <!DOCTYPE HTML> <html lang="en"> <head> <title>Custom PW Login</title> </head> <body> <form action='./' method='post'> <div class="login"> <? if($input->post->user && $input->post->pass) { echo "<p class='error'>" . $session->login_error . "</p>"; }?> <p><input type='text' id="user" name='user' placeholder='Username'/></p> <p><input type='password' id="pass" name='pass' placeholder="Password" /></p> <p><input type='submit' class="btn" name='submit' value='Login' /></p> </div> </form> </body> </html> <? die(); // don't go any further if not logged in } // end !logged in ?> In any template you wish to protect: <? require("./includes/login.php");?> To trigger a logout: <a href="?logout=1">Logout</a> Note: I'm using the HTML5 placeholder attribute. Browser support is not 100%. You may want to use labels instead, or use some jQuery (like I did) to add the placeholder text for browser that don't support it. SideNote: How do you get code indents to stick when posting? I'm having to go back and add spaces to each line. I use tabs when coding.
    1 point
  38. Hi lance, welcome. PW is very flexible and has no "Site" title as it's mostly something you set/code in your template. However you could use any field or page title field as the site name from any page you like. So maybe use the root node "home" on the top of the tree to define a site title for your website. To for example simply output the title from the root page use echo $pages->get("/")->title; Or if you want you could create a simple textfield ie. "site_title" and add that to the "home" template in PW. Then you simply change the above to echo $pages->get("/")->site_title; Another possible route is to use config file to add a title in /site/config.php $config->site_title = "MyHomepage"; then to you can access it from any php template like echo $config->site_title;
    1 point
×
×
  • Create New...