Leaderboard

Hi all! I have created this new module that improve the current search engine on PW: https://github.com/USSliberty/Processwire-site-indexer (Beta version) The main idea is to create an hidden field that store keywords (separated by space). The keywords are generated automatically from all text fields in the page, plus PDFs and DOCs files. So if you create new text fields you can forget to add they on Search Page Module. The only thing to do after install, is to change the list of fields in Search Page (see attachment). In fact you need to search only in "indexer" field. NOTE 1: At this time the module index only when you save the page. In the next week maybe i will add the complete-site re-index. NOTE 2: The files are indexed with 2 Unix packages (poppler-utils & wv). I have tried without success with pure PHP classes, but if know a class that works fine i can add it into module. ADB

@Diogo, I haven't had time to test the second version. Will do so sometime. Meanwhile, I have been busy playing with the module and here's a taster...a CRUD system for: a db external to PW (see video) PW pages (attached screenshots) Just fooling around at the moment. It is WIP as I learn the ropes of PW. In these examples I am using jTables. Will soon switch this to the great DataTables. Soma has a module of this one in the forums. Here I show how easy it is to implement using your module Many thanks for your awesome module!

To all of you who are new to ProcessWire... 1. Welcome. 2. Ask lots of questions, the community here is friendly and very willing to assist. 3. Just start building something—the learning curve isn't nearly as steep as you might think. 4. It's worth it. Once it starts to click you'll never look back.

$pages->find("parent.template=news-month-archive"); $page->rootParent->find("parent.template=news-month-archive");

One of the changes coming in ProcessWire 2.4 (and the 2.3 dev branch) is that we're switching the database driver from mysqli to PDO. Over the next few days, you'll see the ProcessWire dev branch begin to be compatible with both mysqli and PDO. By the time we hit version 2.4, it will only be compatible with PDO. If you develop modules or templates that perform SQL queries, and you want to have a head start, you can begin make your module(s) compatible now by checking what the DB driver is. Though I'm thinking most modules out there don't do any kind of SQL queries, so it won't matter. But for those that do, I wanted to go ahead and mention it since it'll be showing up on the dev branch shortly (I already have it switched locally). Here is an example that issues the same exact query with the two different DB drivers. $db = wire('db'); $name = "example"; if($db instanceof PDO) { // driver is PDO $query = $db->prepare("SELECT COUNT(*) FROM my_fake_table WHERE name=:name"); $query->execute(array(":name" => $name)); $count = $query->fetchColumn(); } else { // driver is mysqli $result = $db->query("SELECT COUNT(*) FROM my_fake_table WHERE name='" . $db->escape_string($name) . "'"); $row = $result->fetch_row(); $count = $row[0]; } If you have any queries that you aren't sure how to convert from mysqli to PDO, just post them here and I'll code it for you.The PDO queries tend to be a little more verbose most of the time (even if not above). But the use of named parameters is something that we need, and mysqli just doesn't have them (unless you like using question marks). There are other benefits to using PDO, but the named parameters are the main benefit in the short term.

Hello Everyone - I am pretty new here - came across this CMS based on a friend of mine who has indicated she used this CMS and loves it. So when she says she loves it then I take her word for it - you might know her as Eisteinboi or Mary. I have been a long time MODX user (and I see there has been other MODX users who have jumped over here as well - so that helps me) Did an install of ProcessWire for one of my Personal Projects I am doing here for the Deaf Community here in Houston. So I am looking forward to my Processwire Journey. So now just need to jump in and figure out how everything works. I'm excited about this Processwire journey, and hopefully if I like it - then maybe more projects to build with it. Thanks for making an awesome product! Have a great one! Billy Koch

Hey Mike, I'll do it. But I'm sure you are aware that a discussion like that is going to become rather messy pretty quickly! Thanks, Matthew EDIT: OK, I posted! It's actually easy for me to post strongly positive statements about ProcessWire, since everything that's great about it is on my mind almost every day...

There is a module that's a work in progress for this particular forum software to handle member integration and registrations that I use here: http://www.strategycore.co.uk but I've not released it yet. I should probably start a thread asking for what features people want because I went a bit overboard with that one and used forum topics for comments for articles etc which was all a bit overkill so I should probably release a stripped down version at some point It does make me feel good when people ask if the forums are part of ProcessWire though as it means I've integrated the skin (not my design, not taking credit) reasonably well (taking full credit ) - not easy with any forum software as those of you who have worked with forums will know. Certainly everything is a chore compared to ProcessWire No forum software ever seems to come with a decent API which irks me, but ProcessWire does spoil us in that regard.

This makes sense to me, I've gone ahead and changed it. It should appear on the dev branch next time I'm pushing updates to it, probably later this week.

I also feel that repeaters are not the best way to go for you. Reapeaters are for information that will be needed more than once, In your case would be more than one per company. I'm guessing that you used the repeater fields to organize the information in blocks. If this is right, that would be better done with with fieldset or fieldsetTab. The first one groups visually the fields in the template, and the second, separates them in tabs (in the backend, this is not the answer to your question about tabs in the frontend). To use them, create a new fieldsetOpen field for each of the groups you have there (Applicant Details, Primary Contact, etc...), and it will automatically create also a "fieldName_END" field for each. In your template organize the fields between the opening and closing field of each group, and you will have a nicely organized edit page. Same applied for fieldsetTab, except that it creates a tab for each group instead of only grouping them visually under a name. To create the tabs --this will depend a lot on what js plugin you will use, if you will use one. I will take the jQueryUi tabs as an example--, you will need to organize the content inside the tabs divs: <div id="tabs"> <ul> <li><a href="#tabs-1">Applicant Details</a></li> <li><a href="#tabs-2">Primary Contact</a></li> <li><a href="#tabs-3">Secondary Contact</a></li> </ul> <div id="tabs-1"> --here goes content-- </div> <div id="tabs-2"> --here goes content-- </div> <div id="tabs-3"> --here goes content-- </div> </div> The frontend will ignore the groups that you created in the backend, so you will have to organize everything manually: <div id="tabs"> <ul> <li><a href="#tabs-1">tab name</a></li> <li><a href="#tabs-2">tab name</a></li> <li><a href="#tabs-3">tab name</a></li> </ul> <div id="tabs-1"> <p><?=$page->organisation_name?></p> <p><?=$page->sector?></p> </div> <div id="tabs-2"> <p><?=$page->primary_first_name?></p> <p><?=$page->primary_last_name?></p> <p><?=$page->primary_email?></p> <p><?=$page->primary_phone?></p> </div> <div id="tabs-3"> <p><?=$page->secondary_first_name?></p> <p><?=$page->secondary_last_name?></p> <p><?=$page->secondary_email?></p> <p><?=$page->secondary_phone?></p> </div> </div> edit: I changed the field names of the contact to primary_something, and secondary_something, because they are different info, and they need different names on the same page.

Create custom admin pages easily without having to build a Process Module especially for that. ☞ This module makes it easy to create simple admin pages but you can also create them in much more powerfull way without the need of a module. Have a look at this post written by Bernhard Baumrock to know how it's done https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ ------- I just updated the module, I kind of merged the two versions and now it works with both stable and dev versions of PW. Only difference is that with the stable version you still need to create the child pages and with dev version that is not needed. The instructions are on Github. Enjoy ---- Download or clone from Github https://github.com/ocorreiododiogo/pw-admin-custom-pages Module page is here http://modules.processwire.com/modules/process-admin-custom-pages/

In a rare display of personal work I’ve made a photographic site to show some of my pics. I hope you like it. http://stlmv.in/mw

Have read in wikipedia about BPM: Lazy Boys from Redmond

1. Both options could work. The important thing is perhaps there should be a pause to prompt the user to make the choice? A separate script would be nice where one needs to add/replace cover images in future. Of course you can also enable this as an option in the main script where the user would be asked whether they wish to import cover images only or audio as well. I prefer the second option though; one single script but with a prompt to the user if they wish to import cover images or not. 2. ID3v2.4.0 onwards I think (wikipedia). It is BPM. I'll PM you a sample mp3.

Maybe adding something like that would benefit to allow adding scripts and styles before all admin ones. Of course admin templates would have to implement it aswell as long as it's "hardcoded" in admin template. Which in the long run makes it hard to change those parts and every iteration (already were a couple in admin templates) all admin templates suffer from missing something. I could even see go as far as modularize the output so there would be a core module that would be hookable to add scripts and styles more precisely. Just thinking loud.

Definitely worth the investment !

Ah you get that error on front-end! Yeah then it's because you overwrite $config->scripts. Yeah the module does also get init'd on front-end as all autoload module does, but the hooks also get executed. I just updated the module now to not add the hooks when on front-end.

You beauty diogo! Everything has gone as planned. As I said, Processwire so intuative and easy to use... I have new insight into the repeater field now too. Will use those in a different light. Thanks for your help Wanze and diogo - both invaluable... Regards

OK, so I went all crazy and decided to do a demo CRUD system....Posted in this thread...

Thanks diogo. I'm putting my trust in you and moving forward on this.... Someone stop me if you think it'll end in tears... I'll keep you posted. I can't believe how intuative ProcessWire is! Loving it, after all these years of bloated CMS/Blog platforms...

@Soma, nice catch, hehe! I was typing as fast as I could so as to beat you to a response

Welcome Billy! If you're looking for a forum this might be a choice http://fluxbb.org/ easy and lightweight software. There's no real forum module for PW (yet except the one from apeisa) but it's also because there's many good out there full featured.

I love that reaction PW causes....

Haha! Yea they do that then complain how slow the site is, and how cluttered it is. And once they touch PW it will be like what was I complaining about again? Again - I am just as much of a hatchling as you are Gray - After only discovering it the other day! Coming from doing a bit of Wordpress, Drupal, Joomla, Umbraco, MODX, and now looking into PW (Which I don't think I will be disbanding at all and start using for future projects). I can say that I like the flexibiity that PW offers. Granted I can see I have a learning curve ahead of me - but I'm gonna hammer it and us lil hatchlings gotta stick together and get through this. Hang in there!

Hi galaxy and welcome, Right now you're looping through the fields of your page, which outputs you the repeaters. You need to loop through a repeater to get the fields in it, that's one level deeper. You could write the html markup for the tabs and then just output your data in it: <div id="applicant_details"> <?php foreach ($page->applicant_details as $d) { //applicant_details is the name of your first repeater echo $d->organisation_name . ' ' . $d->sector; //These are your fields inside the repeater } ?> </div> //.. Next tab Are you sure you need that much repeater fields? People new to ProcessWire sometimes make heavy use of repeaters - usually it's better to model your data with pages. Then use Page fields (single or multiple) to create relations.

Holey Smokes! Where have I been! Now I can see why a bunch of MODXers have been jumping over to ProcessWire! I have been playing around with it and going through the tutorials! I have to say so far I LOVE IT! This is going to make my life so much easier! Thanks for making a great product! So got a goal to finish one site by this weekend! Keep up the great work! *But I know I have so much to cover and go through but heck I love what I see so far* One small question though - this forum - is this also an add-on to ProcessWire? *I have a community site I would love to build and if I can add on a forum that would be absolutely SPLENDID*

Hi, here are the first SiteProfile: There is currently some weird behave with the importer. So if you will run into something similar, it is only a intermediate state to create duplicate artists ;-) Also the importer part has to be more justified when it comes to duplicate Tracknames but from different Artists/Albums. - All of it is in a very basic an early state! But if you like to play with it you are welcome. If you do some tweaks (regardless of frontend, backend, module-code) please share it here.

Yes helper functions like this can be included using a separate php like in the head.inc and used throughout your templates. I extracted this function from a module I have for a project. This module has various helper function and then I load it in the templates. It's much the same as if I would include a php with functions and just personal preference. For example: $helpers = $modules->get("TemplateHelpers"); then use it like this where I need it. echo $helpers->wordLimiter($page->body); I'm not sure what you mean by applying the function to the body. I use this function to create teaser texts that are limited, and show the complete body only on the detail page. Of course you could modify the body output, that every time you do an echo $page->body, it will run it through a function, but I'm not sure this is a good practice. This using a hook on the formatValue of textfields would do it: (directly in template like a include, or by making it a module) function wordLimiter(HookEvent $event){ $field = $event->argumentsByName('field'); if($field->name != 'body') return; $str = $event->return; $limit = 150; $endstr = ' …'; $str = strip_tags($str); if(strlen($str) <= $limit) return; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $event->return = $out .= $endstr; } wire()->addHookAfter("FieldtypeTextarea::formatValue", null, "wordLimiter"); // now this will trigger the above hook echo $page->body; But it's a little cumbersome, as you can't set the limit. Also this strips tags and on HTML text you'll lose formatting. But just to show adn example what is possible. From your post I guess you like to do something like: echo $page->body->limit(150); // not possible It's not possible to do this, because the $page->body, body is just a string and not an object you could add methods to it. But something like the following would be possible using hooks. echo $page->wordLimiter("body", 120); You can use addHook to add a method wordLimiter to page: function wordLimiter(HookEvent $event){ $field = $event->arguments[0]; // first argument $limit = $event->arguments[1]; $endstr = isset($event->arguments[2]) ? $event->arguments[2] : ' …'; $page = $event->object; // the page $str = $page->get($field); $str = strip_tags($str); if(strlen($str) <= $limit) return; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $event->return = $out .= $endstr; } // this will add a custom method to Page object wire()->addHook("Page::wordLimiter", null, "wordLimiter"); // now you can do this echo $page->wordLimiter("body", 100); // or this echo $page->wordLimiter("summary", 100);

What any newbie should do first is learn Drupal. After 2 years of: awful theming, i.e. $element['#object']->field_video_embed['und'][0]['value'] instead of $page->field_video_embed searching through 500 line arrays to find out what module is injecting a certain markup in your code writing huge css files to deal with the divs nested within divs nested within divs nested within divs figuring out how to add a meta tag to your <head> using an API and an array getting carpal tunnel syndrome from constantly clearing the cache because Drupal is such a hog, everything has to be cached learning the Views module, a point and click interface that is 3X more annoying and difficult than learning and using straight SQL find a good host that is beefy enough to deal with the Drupal and has advanced caching capability After that, PW will be a walk in the park.

The disadvantage with uniqid() is that its output is predictable since the value returned is based on the current timestamp. So on the surface, it seems there's possibility for that to be exploited, although it might be challenging. The password generation I put in the example above is based all around random characters, which aren't predictable other than the set which they come from (a-z2-9) and the length (between 9 and 12). I think this is pretty strong. However, the security of it could be increased by adding more to the set of possible characters (punctuation, upper/lower, etc.) and increasing the possible length range, like up to 30 characters or something. I opted to limit the character set and exclude the letters that are easily confused with each other, like "o O 0" and "i I l 1", just in case people are hand-typing (rather than copy/pasting)… less support burden. Another thing I might add to the code would be to make it only work with users of a certain role. But that would be pretty site-specific, so left it out here.

...and among a million other reasons, it's responses like this that make Processwire incredible. There's a lot in there I can learn from. Thanks for sharing.