Leaderboard

Seems like I've got the first job thanks to the developer directory

Some time ago I developed a module (FieldtypeImageExtra) which extends Fieldtype Image with the ability to add custom fields to an image. This worked well but it had a somehow restricted applicability and did not meet all of our needs. There of course are other useful image modules like CroppableImage or ImageFocusArea, but up to now there was no possibility to combine image cropping with custom fields support. So you had to decide whether to add image cropping or the possibility to add custom fields because each of those modules sets up their own field type (and input type) which cannot be combined. The new module ImageExtra allows you to have both functionalities. You can get the module from GitHub. For more informations have a look at this blog post. If you notice any problems or unexpected behaviour please let me know.

Each entry in PageTable is a page and can have it's own template file, just like a normal page. So you can create a template file for each and use the $page->render() to output the markup. Like Martijn's code showed. It's very convenient and flexible reusable. foreach ($page->table as $row_page) { echo $row_page->render(); } the template file for "text" may just contain <div class='row'> <?php echo $page->body ?> </div> And so on.

Thanks Nico. I think we got all sections assigned to someone already but sure there's always enough to do. I'll have a look when I get to it. A good question. The difference is that it's more of a reference with examples for each API method or property. The documentation pages are good to get understanding with examples and the cheatsheet is built from the content from there (just without examples). Idea is to extend it and provide more examples for stuff that isn't covered on the docu pages. See it as a more comprehensive and compact version like the php api pages with comments and cross references. Most important maybe is that we all can edit those and have some cool options that the docu pages don't have.

Dear All, Here is the demo for the site profile. Demo - bluevr.webcreate.lk Thanks

The seems to be a bug with the CSS compression. #nav :hover{} becomes when compressed: #nav:hover{} The blank should not be removed as it is a separator between a parent and a child element and removing it changes the cascade! The the first rule identifies a child element of a #nav element which is hovered over like the anchor link in this HTML snippet: <div id="nav"><a href="/">I am a hovering child element</a><div> and the latter identifies just the #nav element itself which is hovered over like: <div id="nav"> I am a hovering parent element. My children don't matter. <div> As a consequence this bug breaks CSS based menus.

I did another quick module, which plugs something I always kinda missed in ProcessWire. It's just a raw overview over the access management from the templates. Nothing fancy, but useful. The visible roles and the visibility of system templats can be setup in the modules settings. I'll add this to the modules directory later. But for now it would be great to hear if anyone is missing anything or if someone does have a better idea how to name the module. 12.03.15: Renamed the module and fixed wrong information for superusers and inherited rights from the required guest role. GitHub: https://github.com/LostKobrakai/ProcessAccessOverview

Your last code makes a lot more sense sense. All previous code and errors didn't had any of $header... Then you solution was <php $header=$pages->get('pagenumber'); ?> Which makes no sense. $header wasn't anywhere in header.inc and further $pages->get("pagenumber") doesn't do anything in PW. Now using a integer <php $header=$pages->get(1012); ?> // '1012' works but looks wierd as it's a string and not a number Is a different story as it will load a page with ID 1012. And with the new header include you show posted there's suddenly a $header->scoial_icons etc. Anyway happy your colleague was able to help you out

Hi! This is my first post and I hope I am doing it in the right place. The question is a bit complex but I guess someone might be able to help. 1) We made a site in processwire: www.beaglemarketing.com 2) We made it multilanguage so for example spanish is under /es/ etc. 3) For SEO reasons we want to run the spanish site under a different domain (www.marketingautomation.es) but we wanted to avoid to have two different codebases for a site that is exactly the same.. but translated. 4) We decided to make a copy of all the files to the www.marketingautomation.es domain, share the same database and then do some smart .htaccess tricks so /es/ runs as the root domain. That is, spanish, even if it is a folder, will feel is the default language. 5) So the deal was to redirect www.beaglemarketing.com to /es/ and then hide the directory so all the pages are served under the root. So far I managed to get quite close.... and now I get pages served as www.marketingautomation.com/precio instead of www.beaglemarketing.com/es/precio and so forth. BUT and here comes the question.... I get a bunch of url query parameters that make things look rather like this: www.marketingautomation.es/funciones/?it=es/funciones/ when I would like to have just www.marketingautomation.es/funciones It is possible to do what I am doing? When I tried to remove the query string through some .htaccess code I did not manage to do so, and the pages in the site just stopped responding. Anyone that can enlighten us? Thank you very much, and keep this awesome CMS growing strong and healthy! Daniel

Nico, feel free to help me with $file and $image parts...

@pjg: Hey, I implemented the counter you suggested. It's a little bit different from your version but it has the same settings

Fixed this with <?php if ($page->next->id) : ?>

@Christophe: Naming wouldn't have made a difference as the files you include can be called almost anything as long as the code contained within them is valid php. As a matter of fact one of my standard include files is called "onions" (without suffix etc) purely because it amuses me when I can resolve an incident with the explanation that "I have lost my onions"... The latter suggestion merely provides context to human (and certain machine) readers, which in the final evaluation of the code is ignored by the server.

One thing when cropping to large sizes (eg 1000px or so), then on hover preview won't fit on the screen - perhaps it can be displayed at a smaller size when it is greater than a certain percentage of the viewport size? Sorry in a rush, but if this doesn't make sense, please let me know.

The CSS compression bug I described in my earlier post has been fixed in AIOM version 3.2.

This is so cool! Thanks for creating.

Maybe try to enable debug mode (in /site/config.php) and see if there are any errors.

Did you put any data into those fields for the page you are viewing?

Discussion can be continued even if the issue is closed, by the way. That being said, I always felt that GitHub issues are not a good place for discussions or feature requests anyway, but I guess that depends on how one wants to use GitHub issues. I really don't follow the PW repository closely enough to even comment on that, it's just my experience from other projects that discussions and feature requests tend to extend issues to a length close to being unreadable. The same is true for the number of open issues or pull requests – it really depends on how someone looking at the repo views them. I know I tend to shy away from projects that have a lot of open issues and PRs, but one should in fact always look at the commit log as well to check how active a repo is. Maybe a hint concerning all this in the README (“How Processwire handles issues and pull requests” or something) would help clear that up?

Had to add a character counter with limiting functionality for one of my projects. Take a look and let me know what you think for now https://github.com/pjguk/MarkupSEO No guarantees given - this was "hacked" straight into a production environment which already utilises the module and therefore uninstalling and reinstalling was not an option for the time being. Particulars that are most likely not working as expected for now (Couldn't reliably test yet): Default character limits are not set on install Default character limits do not set should the limit field be empty when the page is saved Hard character limits do not apply to pages unless the fields are being edited and the page subsequently saved (requirement for my project, may not be the behaviour everybody wants/needs) So still some teething problems with the config on that part, but works well enough for me for the time being. The modifications allow the following: Counter added to the title and description fields in the SEO tab. Counting down from the limit to 0 - and beyond to show how many characters you are over. Config options in the module settings to set the character limits for title and description as well as toggling hard limits. Hard limits disable the ability to enter more than the limit number of characters. Useful if multiple authors work with the SEO tabs and you want to ensure nobody goes over the limits. With hard limiting disabled the character counter simply goes into the negative and ignores the limit for the actual input and render. With hard limiting enabled the input cuts off at 0 characters left.

yeah, it works really well... probably should make this into a module at some point, for wider accessibility

Sorry, just copy&pasted from my code, so I used {} instead of php tags as the snippet I copied from was within a PHP echo(). <?php echo $config->urls->templates; ?>bbp/img/logo.jpg should always point at the same logo at "[YOUR PW DIRECTORY]/site/templates/bbp/img/logo.jpg". Basically, it shouldn't matter if you're using $config->urls->root or $config->urls->templates, the latter is just a little shorter and more "speaking". I'm not completely following what you mean with "on the page itself while inserted in the article". Can you give an example?

I just viewed the video of the mentioned drupal module and I can see, that this would be useful for the client, because his workflow doesn't have to change. Also using only a single database instead of some kind of mirroring is nice, too. If you want to do this the most flexible way, you could do a set of extended Fieldtypes (text/date/image, what filemaker offers) based on the core ones. But you'll change the methods which interact with the database, like sleep- and wakeupValue and so on. I don't know how complex this would be, but you would get kinda nativ processwire objects out of it. The less elaborate version would be just 3 new fieldtypes, Fieldgroup, Field and Portal. If I understand it the right way, there's really not more about this databases.

@Richard, something like this: foreach ($page->table as $row_page) { echo $row_page->render(); }

I'm migrating our corporate Intranet from Contenido to PW. ~8500 pages, 2 languages, 400+ users, about 20 modules and templates. I'm a little more than halfway there right now, most modules are working as planned and the first migration tests look promising, though I'm pretty sure a few headaches will be popping up when I start with bulk imports (though those won't be PW's fault...).

This one is fixed now: The PW $config with recent dev versions now contains or can contain a variable logs: /*** 9. MISC ************************************************************************************/ /** * Additional core logs * * All activities from the API functions corresponding with the given log names will be logged. * Options that can be specified are: pages, fields, templates, modules * * @var array * */ $config->logs = array( 'modules', ); Per default it is set to include "modules". I have changed the croppableimage module to suppress loggin if this is enabled. If you use it with a recent dev version please update: https://github.com/horst-n/CroppableImage And I have tested it with PHP 5.3 and it works, so the requirements are updated too.

I'm building a series of Process Modules for internal business functions. We have several processes that require complex forms. More than would be feasible to create using pages. So I decided to use FormBuilder to allow the appropriate users create and maintain the forms. There would be way too many fields required to send all these forms to pages using the built-in FormBuilder process. These are all lengthy forms (and this is a University), so think 10+ forms — some with up to 60 fields. Rather than save the form to a page, we hook into 'FormBuilderProcessor::saveForm' and create a page that references FormBuilder entry. (The page title is the same as the form entry, for example 1.817) I got a few tips from Ryan on that part. There is one base module called "ProcessAdminForms" that has all the common functionality. The modules that extend it can get as specific as needed. The screenshots below are from the "ProcessAdminIPIFs" module. It is an internal HR process that is required to hire a new employee or setup a new vendor. List of entries Show/hide columns (state saved per user via cookie) Viewing an entry Administrative comments & notifications

BTW if you search for "processwire flexible content" in google you'll get lots of lengthy discussion already there.

You mean a Cook Book? ;P Don't think official yet, but If you search for ProcessWire PageTable you'll get tons of. https://processwire.com/talk/topic/6417-processwire-profields-table/?p=63119

I have a hard time understanding what people mean by "MVC" sometimes, but it seems to me that the PW module system is natural for building this way. You can set the module to autoload and then use it as your Controller. Keeping all your logic in there, the template then becomes your View, and the Pages API already handles the Model side of things. But I could be totally wrong...

In a way it's sad that companies praise the way of reinventing the wheel. But that's business.

Steve - thanks for the module - it has proven very useful, however I wonder if you'd consider having multiple rules so it would be possible to redirect some roles to one page and other roles to a different page, etc? I might end up making the changes myself and submitting a PR if you don't have the time to tackle it, but hoping you might

Hi tehandyb There is a rough translation between traditional terms and ProcessWire's, which is: Templates = tables Fields = columns Pages = rows Template files = controllers & views In ProcessWire, you would create the necessary fields for your content, add the to one or more templates (to define your "schema" in a way), and you create pages based on those templates. The page output is handled by it's template's file. The fields you add to the template can vary from integers to text input to map markers (and more). In your example, you would probably want to create templates for at least event and location. Users, roles and permissions already exist in PW, but you can extend these for your own needs if you have to. The key to linking pages together (individual users, locations and events) is the Page fieldtype. This allows you to create a field that can reference one or more other pages of a type of your choosing. Back to your example, I'm going to presume an event might have one location or none at all. First, create a location template with the basic fields you need. Create a section of your page tree to store them. If you don't want them to show up in lists or searches, set the parent to Hidden. Then, create a new field called location and add it to your event template. Configure it to list pages with a template of location and the parent page where they're stored in your tree. You can also choose what type of inputfield it will use - a Dropdown or PageListSelect might be appropriate depending on how many you have. When you have done that, creating or editing an event will allow you to choose a location from the list. In the event template file, you would access it like this: <p>This is the <?php echo $page->title ?> event.</p> <p>The venue is: <?php echo $page->location->title ?>.</p> I'd recommend reading some more documentation and this brilliant thread on categorising your content.

TemplateBy adding the fields you desire to a template you basically model the content/data that you want to manage. Template file Associated to a Template, a template file is where most of the view and controller logic takes place. PW is very flexible so you can also make this more MVC-like, look at this for an example: https://github.com/fixate/pw-mvc-boilerplate/tree/develop Page A page is a data object that always follows the rules and data structure of the associated Template (you could say model). In PW pages are tree based (parent-child relationships). This gives powerfull options of organizing and relating content. Routing PW has a default way of routing following the page tree, but by utilizing urlsegments or hooking into the routing mechanism you can define your own if needed. So PW has it's own way of doing things. It may take some getting used to, but in my opinion it is a very nice way to model and manage your data. I believe one should always choose the right tool for a certain job, so there might be projects that are better suited to build from the ground up using a general purpose framework like Laravel or Symfony. But in my experience PW is the right tool for a whole lot of stuff.

You've to use a 'lower' hook: $this->addHookAfter("ProcessPageEdit::buildForm", $this, "example"); // From there you can find all tabs // settings tab $settings = $form->find("id=ProcessPageEditSettings")->first(); // content tab $content = $form->find("id=ProcessPageEditContent")->first(); // view tab $view = $form->find("id=ProcessPageEditView")->first();

None that I know of, but you can always do this: $fs = array("body", "title", "summary"); foreach ($fs as $f) $page->save($f); According to Page.php, for single field save you'll want to hook into Pages::saveField(). Isn't this exactly the same question that Wanze answered quite a while ago, or am I missing something? If you still need those wildcards, then it could, of course, get more complicated

Ok, I have quickly hacked together some enhancements to Wanze's Batcher module. There is now a Create Fields tab where you can enter the details (name, fieldtype, label & description) for as many fields as you want. A couple of things to keep in mind - some field types require some key config options on the Details and Input tab, so in some cases I am not really sure how much time this will really save. Because of that I have currently limited the field types that can be created to simple text based ones (text, email, url, numeric etc), and left out the more complex ones like page, repeaters, datetime etc. Of course there is the potential to add some of these settings to each item in the create field batcher, but we wouldn't want things to get overly complex. Also, I am not really sure of the etiquette here - I have modified Wanze's module and he may not want to see this functionality in his module (which would be totally fair). So what I have done for now is just include a screenshot of what I have created and I'll wait to hear from him to get his thoughts before posting the code.

i tried Pete's code but it wasn't working; i made some changes based on seeing similar things on other modules, so here is a version that is working for me on latest stable: <?php class BuildUrl extends WireData implements Module { /** * Basic information about module */ public static function getModuleInfo() { return array( 'title' => 'Build URL', 'summary' => 'Builds a URL on page save based on specific fields.', 'href' => '', 'version' => 001, 'permanent' => false, 'autoload' => true, 'singular' => true, ); } /** * Initialize the module and setup hooks */ public function init() { $this->pages->addHookAfter('saveReady', $this, 'buildUrl'); } /** * * @param HookEvent $event */ public function buildUrl($event) { // Accesses the $page object $page = $event->arguments[0]; if($page->template != 'product-child') return; $page->name = $page->title; $this->message("slug changed to " . $page->name); } }

That's a good idea. Though I'd still be nervous about it. Something to think about adding though... One way you can override things on your own is to edit the Fieldtype module file that you want to convert from. So if you've got a float that you want to convert to a string, edit /wire/modules/Fieldtype/FieldtypeFloat.module and add the following function to it (temporarily): /** * Return Fieldtypes that are compatible with this one (i.e. ones the user may change the type to) * * @param Field $field Just in case it's needed * @return Fieldtypes|null * */ public function ___getCompatibleFieldtypes(Field $field) { $fieldtypes = new Fieldtypes(); $fieldtypes->add($this->fieldtypes->get('FieldtypeText')); return $fieldtypes; } If the Fieldtype you are editing already has that function, that you could just modify it according to what you need.

lovely boot-strap it.does http://processwire.com/api/include/

I'm not sure this describes what it actually does, or I might be misunderstanding what you are trying to say. But what actually happens is that the template file assigned to the accessed page gets executed, as a PHP file. ProcessWire spits out no content. You have to specifically code your template file to spit out content. ProcessWire does not participate in this aspect, only you do. That template file is handed a copy of $page, which represents the page that was requested by the URL. Whether you choose to do anything with that $page is up to you. This is an architecture that ProcessWire supports. Make all your pages use the same template file and this is what you will have. This doesn't mean all your pages have to use the same 'template' (unless you want them to), just the same 'template file'. To achieve that, edit each template, click 'Advanced' and set the 'Alternate Template Filename' to be the one you want to be the top of your pyramid (i.e. main.php). Another way to do it is to maintain separate template files that just include("./main.php")). Either way, all valid requests will be routed to your main.php with $page being the only thing different from request to request. If you want requests routed to your template file that don't map to URLs in ProcessWire, then edit the template settings and turn on URL Segments in the URLs tab. Now all URLs below the page(s) using that template file will be handed any URLs below them that don't map to pages. You can then map $input->urlSegment(n) to whatever you want, whether a function/class method, another $pages->get/find call, another application, etc. This is a lot of fun to be had in here. You can do this, but your htaccess will have to identify the paths that get directed to your own script by looking for them with a rewrite rule. Or you'd have to put your script in a directory that is the same as the URL used to access it (or at least, the first url segment is the same). The htaccess file does not know which requests will result in 404s. It doesn't know what is "non-cms" unless the request is to a real file or directory. ProcessWire is what ultimately generates the 404.

Adam, that's a pretty slow page render time you had there. I don't think that can be attributed to taking an MVC approach, so am guessing there is some other factor at play that caused the bottleneck. If you want your current template file to be a controller pulling in other views, then use the TemplateFile class and place your view files in a directory like /site/templates/views/ $t = new TemplateFile('./views/list-news.php'); $t->set('items', $pages->find('template=news, featured=1, sort=-date, limit=3')); $out = $t->render(); Your /views/list-news.php file would look like this: <ul> <?php foreach($items as $item): ?> <li><a href="<?=$item->url?>"><?=$item->title?></a> <?=$item->date?></li> <?php endforeach; ?> </ul> If you are using this approach, it is far more efficient and straightforward to keep the foreach() in the view rather than calling up a new view for each item. It also gives the view the opportunity to handle an empty condition (if you want it to), and it prevents separation of the container from the items (i.e. you aren't splitting a <ul> and an <li> in separate files). Another approach (and the one I like to use) is to use a module as a view. I'll create an autoload module that adds a 'renderNews' (or another name as applicable) to the PageArray class. Then I get the output of that view like this: $out = $pages->find('...')->renderNews(); It's almost as easy with a normal, non-autoload module: $m = $modules->get("MarkupRenderNews"); $out = $m->render($pages->find("...")); Of course, the same approach can be done just by including a set of functions as views and calling upon them as needed, though I prefer the structure of modules for this stuff. But the end result is just as simple: $out = render_news($pages->find('...'));