Leaderboard

I've been using clamp http://jide.github.io/clamp/ for a while now, rather than installing MAMP or MAMP PRO. Like MAMP, it delivers Apache, MySQL (via MariaDB), and PHP. Unlike MAMP it runs from the command line (the 'c' in clamp). Also unlike MAMP, all settings and data (database), sit alongside the website files in a .clamp folder (you need to add this to .gitignore to stop dev environment leaking into production). Apart from being free, it's just brilliant to use. If you get errors or stuck, check the logs, the docs are brief but excellent. Enjoy!

@dweeda worth noting that you can also do $urls->templates as of 3.0.50

I faced with a very similar same issue (here) in the past. There's some good discussion and solutions in that post. To summarize: If you're not using "Allow new pages to be created from field" feature, you can provide a selector string or hook into "InputfieldPage::getSelectablePages" to return only the pages you want to appear. If you're using Autocomplete inputs or creating new pages from the field it wont work. There's no elegant solution to this as far as I know. But, you have several options: Duplicate the page field and add both to the post template. Hide one or the other depending on the parent. Duplicate the template as well and add a single field to a template (and distinguish it with blog-post & news-post). Then you can include one template file inside the other to reduce duplication etc. Hope this helps.

Hi @dweeda Try <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates; ?>styles/NavUserHdr.css">

I think we need something like UserVoice for PW feature requests, so Ryan and other core developers can gauge the level of support for individual requests and prioritise accordingly. It would actually be good to have the same for PW issues, so we can get an indication of which issues are particularly problematic to the largest number of users.

@Macrura Thanks for the purchase. Sorry for the late reply. Been working on the next release which addresses all the issues raised. Done in next release. Me neither! I couldn't remember why I set it up that way! I think I confused that to mean 'allow more than one image from one page to be visible as selectable' Yep, that's how it is set up now. If image field in the selectable page is a multi-image field, grab the first image. If it is a single image field, grab that one image. In essence, VPS will always grab the first image. The issue is about the image field in the selectable pages. VPS should (and now does) work with both single and multi-image fields. Like @Macrura explained, there will be cases where you want to reuse an image field for other needs. Or imagine a case where you wanted to show related images in the frontend. For instance, for a real estate website, you may want to have different photos of one property: In ProcessWire, create a photo page with a multi images field for your property for sale. Upload various photos to the multi images field on that page, making sure that the first image is of the front of the house, for instance. Make your property page selectable in the page field you are using with VPS. Edit a page with this page field that is using VPS In the selectable pages modal in VPS, for this particular property photo page, you will see only ONE image; the first image. That should be enough for editors to know what image/selectable page to select. Underneath the hood, we/they know they are just adding a reference to the photo page (in the page field). In the frontend end, when displaying the page with the page field in #4, since the page field has a reference to our property's photo page, we can now show all the photos of our property that we uploaded in #2 . Sorry for verbosity but hope this explanation makes things clearer (not in the least for me!). As you can see, this should not affect the current workflow of one page for one image. Your selectable page with a single image field will still work as is. You will see its one image in the modal for selection and will be able to add it to your page field. Speaking of which... This is now fixed. VPS will work with both single and multi-page fields. In summary, you can have: Selectable page with a Single image field to add to a Single page (VPS) field Selectable page with a Single image field to add to a Multi page (VPS) field Selectable page with a Multi image field to add to a Single page VPS field Selectable page with a Multi image field to add to a Multi page VPS field The most important thing to remember is that in the selectable pages modal, VPS will always show one image per selectable page. It doesn't care what lies underneath. This means that you can even have a selectable page with with several image fields and if those image fields are specified in VPS image field settings, VPS will always return the first found image in the first named image field. It means that if one image is deleted or images are reordered or one image field removed or the named order of images in VPS field changes, VPS will always get the next available of the remaining images. Done! I believe this has been requested before by @Robin S but it slipped under the radar. You can now configure VPS to separately allow editing of both selectable and selected pages (i.e. both in the modal and those already in the page field) for all views (Modal: Thumbs and Lister; Page Edit: Thumbs and List). Default is not to allow editing. Page-editable access is also respected. Sorted. You now see a clean modal view with just the edit screen as well as a 'Back' button to take you back to the listings/thumbs of all items. As said above, the edit button will only be visible if you've allowed editing in modal window. If using thumbs view in the modal, and you've allowed editing of selectable pages in the modal, the selectable pages' titles will be clickable, taking you to the edit screen of the page. If a page is not editable, they will see a normal/unclickable title. In the field settings, under VPS: Modal settings, in the Page Selector View option, if you have Lister view selected, you will see more options under VPS: Lister Settings. In particular, see Limit Selectable Fields/Columns and Disallow Columns. Please see this section of the docs. No you can't, at least not from VPS side. I'm hoping to release version 4 of VPS either today or tomorrow.

Hi @szabesz! Yes, it works! I'm running it on PW 3.0.57 right now, in production. I have two actions: 1 - "Generate Short URL on adding a page" - On page save, it calls an API on another server (mine too) that runs an installation of https://yourls.org 2 - "Set end date on events, if empty" - the name is self explanatory.

In a current project I am using a Repeater field to build a kind of pseudo-table, where each Repeater item is a row. Some of the rows are headers, and some have buttons that toggle corresponding checkbox fields in a hidden FormBuilder form. The problem was that when the Repeater items were collapsed I couldn't see which rows were headers and which contained buttons. I tried including the fields in the Repeater labels but it still didn't provide enough visual difference to be quickly recognisable. So I investigated how classes could be added to selected Repeater items in admin depending on the value of fields within the Repeater items. This is what I ended up with... In /site/ready.php // Add classes to selected service row Repeater items $this->addHookAfter('InputfieldFieldset::render', function(HookEvent $event) { /* @var $fieldset InputfieldFieldset */ $fieldset = $event->object; $attr = $fieldset->wrapAttr(); // Fieldsets in a Repeater inputfield have a data-page attribute if(isset($attr['data-page'])) { // Get the Repeater item $p = $this->pages((int) $attr['data-page']); // Check field values and add classes accordingly // If item is a header if($p->row_type && $p->row_type->id == 2) { $fieldset->addClass('header-row'); } // If item has a checkbox button if($p->fb_field) { $fieldset->addClass('has-checkbox'); } } }); In admin-custom.css (via AdminCustomFiles) /* Special repeater rows */ .Inputfield_service_rows .header-row > label { background:#29a5aa !important; } .Inputfield_service_rows .has-checkbox > label .InputfieldRepeaterItemLabel:before { font-family:'FontAwesome'; color:#73cc31; content:"\f058"; display:inline-block; margin-right:6px; } Result

And I was sure YOU will ask that ! Sure, I am already trying to get back my Gitlab server. The server was hosted in a VMware guest machine, and when plugged the hdd and put the virtual machine ON, the network simply does not work anymore. Can't ping anything, but I know how to fix it, i am just too lazy those days. Edit: Just to say, I still have the code and used the module in the last days, but it look like its not the Windows compatible version..

Hi @flydev Nice to see you again. Looks like you are back on track. Any plans on working on this great module again? You have probably been waiting for this question

Thanks for your quick response, abdus, and for providing a link to the earlier discussion. Rather than spend any more time on a solution, I think I'll just create two different templates based on your suggestion. Thank you!

@oma Call SendGrid like that : new \SendGrid(); (As Adrian said, its a namespace issue) @teppo I used WireFileTools just for the example, the bénéfit of this class is that it provide the ProcessWire API to the object. Sorry for the short answer, i am on mobile.

No - you are experiencing a namespace issue - looks like the function is being defined in the global namespace, but you are calling it from within the ProcessWire namespace.

A standard php include works fine for me in a hook. Any chance it's a path problem?

Actually require_once() works just fine for your example. I'm not sure what kind of a problem you're having, but I'm pretty sure that it's not related to require_once() not working in a hook, at least. One issue I can spot right away is your comparison, where "if ($page->template == user) {" should probably be "if ($page->template == 'user') {". It also seems that you've omitted some closing curly braces, but if that wasn't even supposed to be a fully working code sample, so perhaps this was intentional

What's happening in the screenshot? Are you getting the same category where you should be getting three different categories? Is that the issue? Otherwise a Page field that accepts multiple pages should suffice for assigning a post multiple categories. The code you've written should work. However from $kategoria->recept I think you want to get to other receptek (recipes) related to a given category inside the loop. For that you can use $pages->find("kat_page=$item, id!=$page") to find other recipes with the same category (excluding the current page). Or as a more performant solution to get a 2-way relationship (to find categories related to a recipe AND recipes related to a certain category) you can use @Robin S's module http://modules.processwire.com/modules/connect-page-fields/

Yes you can. $this->addHookAfter('Pages::save', function(HookEvent $event) { $arguments = $event->arguments(); $page = $event->arguments(0); if($page->template == 'user') { // Require relevent libraries $wft = new WireFileTools(); $wft->include('sendgrid-php/sendgrid-php.php'); $from = new \SendGrid\Email("Example User", "test@example.com"); $subject = "Sending with SendGrid is Fun"; $to = new \SendGrid\Email("Example User", "test@example.com"); $content = new \SendGrid\Content("text/plain", "and easy to do anywhere, even with PHP"); $mail = new \SendGrid\Mail($from, $subject, $to, $content); $apiKey = getenv('SENDGRID_API_KEY'); $sg = new \SendGrid($apiKey); $response = $sg->client->mail()->send()->post($mail); // dump SendGrid object with TracyDebugger bd($mail); } });

Look like i am going to love it and its a french who made it! ♥ Will give a try soon, thanks for this post @alan

dangit, sorry about that – fixed..

hi, long story short: please make another official demo. one demo for developers and one more ui centered for editors. i know http://demo.processwire.com/regular/processwire/ but its not official. i also think that reno is a bit stronger if the colors would be also as light as in the demo. — so i been talking to a client, who showed ProcessWire to a programmer-friendly friend. This friend knows some Wordpress and together they had a look at the demo page of ProcessWire. Mainly they wanted to see how the backend looks and how it feels. So what i experienced is that the demo page is a show off on how to treat a lot of data. It gives developers an insight into page, template, field and module structure. But they said its too complex editor-wise, so i had to explain to them the idea of the demo and that there are possibilities to make the backend feeling more modern and pure/simple. (the new wordpress backend looks really slick) The default admin theme works well, but in all use cases i use the reno theme, because it feels alot more modern. i also remove access to setup / modules and access to focus the editor towards pages. (probably i will do a black and white / one-color version of this in the near future to get rid of colors not fitting the project, or probably there is some?) — (the website processwire.com is »from developers for developers«. it would be great though to have a bit more direction towards »from developers for editors / clients«. because processwire is really easy to use and easy to adopt for editors / clients. this could be more focused.) best, ocr_b

No The global template file has nothing to do with smarty, it is a feature provided by the module that is available for all connected template engines. The global template file only means that you always get the same (smarty|twig|...)-template behind the $view API variable. As already said, you probably don't want to use a global template file with smarty, because you can use smartys template inheritance which is much more powerful. For me, this is the main reason to use a template engine.

I 100% agree that no one needs endless discussions about issues to be solved, what we need is priority and the way to indicate importance. Using the right tool could probably solve this issue.

Seems like the main problem is that the setKeyAndValidate() method is called on every PW ready(). I just commented that out and load times go back to being normal. I don't know the Tiny API, but I would think it would be possible to either just do this once, the first time the API key is entered, or perhaps if it's needed for each call to Tiny, then it could be called only when one of the hooks is triggered. Perhaps @Roope can take a better look since it's his module.

Any chance you could point us to the module code?

Users are pages so you have all the hookable methods in the Pages class too ('added', 'publishReady', etc). So you make the code in the hook conditional on the page template being 'user'.

Are you using a module that has already been posted here, or your own custom one? I am curious if the slow response is only the first time a page is loaded? I feel like the module should be able to cache compressed versions and only ever have to run the call to the service once.

That approach sounds good to me - very flexible. The only dedicated user hook is: Users::saveReady so you might need to add some logic if you don't want existing users altered when their details are changed. Regarding finding appropriate hooks, take a look at the Captain Hook panel in Tracy: https://processwire.com/blog/posts/introducing-tracy-debugger/#captain-hook-panel It makes it easy to search through classes and methods for things you might need and if you have the editor link protocol set up properly, it will open the file to the class/method you click on.

Nothing to be sorry about @flydev. Thanks for your work. Really hope it will work out in your personal matters.

Totally just needed this, thanks

Are you using namespaces? If so then it would need to be (\Exception $e)

I catch the login throttle messages and pass them to a session variable which is displayed on the login page: // login user try { $u = $session->login($username, $pass); } catch(Exception $e) { $session->logout(); // without this line the user will be logged in although the exception is thrown $session->login_error = $e->getMessage(); $session->redirect($pages->get('/login/')->url); } Strange thing is that without the $session->logout(), my login page will show the error message that is thrown by the login throttle but still login the user. Is this intended behaviour?

The page statuses are a bitmask so it's possible for there to be multiple statuses on a page, like unpublished and hidden. So it's best to add and remove statuses with the addStatus and removeStatus functions, i.e. $page->addStatus(Page::statusUnpublished); // same as: $page->status = $page->status | Page::statusUnpublished; $page->removeStatus(Page::statusHidden); // same as: $page->status = $page->status & ~Page::statusHidden; You can also check the status of a page by using the is() function: if($page->is(Page::statusUnpublished)) { ... } // same as if($page->status & Page::statusUnpublished) { ... }