Leaderboard

ProcessWire by default blocks access to files with the extensions php, htm, html, inc and tpl underneath the templates directory (or, to be precise, the shipped .htaccess file does so). This is a security feature. Thus, to access third party PHP code, you have two choices: Move the relevant code outside of the templates directory or create a template with a PHP file in site/templates that includes the external library (in your case instapast-ajax.php, and that's where Ryan's quote comes in) and a page that uses this template (and that provides you with the URL to call from JS)

The latest update contains a fix for IUC links inside repeates, though they doesn't work in ajax-loaded fields - PW doesn't add the markup there, no idea why. There's an "Enable module" toggle too to enable/disable the module without uninstall. Main changes: workaround to use panel mode for repeaters and other fixes for InputfieldURLChecker added "Enable module" toggle layout improvements for sticky and compact headers (RenoTweaks) miniScrollbar now works with stickyHeader (previously only with compactHeader) more general solution for HoverSaveDropdown

The "panel" mode fails for repeaters but that's I think a PW issue (IUC). The URL is opened in a new tab so it's not a critical issue. I have an idea for a solution but I'm not sure it would work. It was a bad thing to realize that PW panels are not dynamic, meaning they are determined on page load, but I found a workaround that apparently works.

Works as far as I have tested it as expected on PW 3.29

I think the problem here is the way you are mixing PHP and HTML together: <? foreach($page->home_sliders as $home_slider) { <li class='orbit-slide'> This isn't valid PHP - you need to either echo all the HTML or switch in and out of PHP like so... <?php foreach($page->home_sliders as $home_slider): ?> <li class="orbit-slide"> ...more HTML... <?php endforeach; ?> As an aside, the short PHP open tag <? is discouraged - the short echo tag <?= is okay though.

would need to be $home_slider->sliderimg->url or $home_slider->sliderimg->first()->url depending on if the image field is single or multi

Better to store the selected pages in a PageArray: $children = $page->children; $uniques = new \ProcessWire\PageArray(); // assumes PW3 foreach($children as $child) { $uniques->import($child->size); } $uniques->sort("title"); foreach($uniques as $unique) { echo "<button class='filter' data-filter='.size_{$unique->title}'>{$unique->title}</button>"; }

v040 brings InputfieldURLChecker to AOS! This also means that the "standalone" IUC module will be discontinued, only this submodule will be further developed. All of its features were kept but some were implemented differently (hopefully for the good), so if you encounter an issue please report.

Thought I'd mention this here too. Both VersionControl.module and ProcessVersionControl.module have been updated to version 1.1.0: VersionControl 1.1.0 includes new public method getHistory($page) for fetching the full history of a specific page as an array (supports pagination and filters, arguments can be checked from the code). The primary goal here was to separate the core logic of the module from display stuff. ProcessVersionControl 1.1.0 greatly improves the diff output for Page fields. Instead of IDs and string diff it will now use actual labels and custom diff logic. This not only looks better, but also makes more sense than comparing a list of numbers and displaying the smallest possible change set between them The Page field update was thanks to this pull request, though it ended up being a bit more complicated than that: https://github.com/teppokoivula/VersionControl/pull/2.

Hello, I made this clone of the Ghost Blog System (http://ghost.org) for demo of the Wire Render Pattern as well as a multi language site and menu system. https://github.com/NinjasCL/pw-ghost As always MIT licence.

v042: modalModuleEdit option to ModalTweaks: edit modules in a modal dialog. Reloads the Modules page on module uninstall. compactModuleList module names are "full-cell" sized for better clickability breadcrumbs ctrl+click fix for Default admin theme

You could try my module MarkupGoogleRecaptcha or implement an honeypot field like in the SimpleContactForm module.

Hi, I've managed to add a new button to the edit page but i'm finding it difficult to catch when it's been clicked. I've attached an image with the new publish later button with the name pdp_pub_later, but when I message() the action its always ProcessPageEdit – who would I find out that my new button has been clicked? public function init() { $this->addHookAfter("ProcessPageEdit::execute", $this, 'publishLaterAndRedirect'); } public function publishLaterAndRedirect(HookEvent $e){ $page = $e->page; $action = $e->action; $this->message('action:' . $this->process); }

Thanks @LostKobrakai I was able to pull my button name as a bool from the page input. $this->postPubLater = $this->input->post('my-submit-btn-name');

Just used this snippet - really great solution!

In a related topic in the ProFields sub-forum @ryan has said: So please log any SQL mode issues at GitHub as they arise so they can be tracked and resolved.

If you mean they display content from your web server in an iframe then it doesn't matter what server technology is involved (PW or otherwise) because the iframe content loads on your server not theirs. You could use a URL segment such as /embed/ so that pages loaded with this segment do not include header, footer, etc but only the panorama content. Might not be something you want to tackle but just wanted to point out that it's possible. I'm not aware of any existing module that does this, but as I mentioned in an earlier post above wouldn't be difficult to create your own module that lists directories as options in a select field. The trick is getting the names of the valid directories you want to include as options into an $options array.

Another version today (039) with a redesigned settings page:

Hi at flydev => you did it again and this time with the foundation grid Thanks for doing this and also making a pre-compiled profile. I am happy to see it is also compatible with processwire 2.7.2. I have uploaded it to a test server online here: http://www.dev8.pe.hu I think I like the friendly foundation grid more than the intimidating bootstrap but that may be just personal expierence. Looking inside the templates folder, home.php, basic-page.php, _main.php, etc. I see you have a deeper understanding of pw api than I do and am happy to learn from there e.g. filling, preparing and render $content. I also saw you did a great job with customizing the backend: Since the issue for me in this is building processwire website templates, I add here franciccio's post where he mentioned a good source of free html5/css templates: https://processwire.com/talk/topic/13589-free-css-templates-css-layouts/ and here are also eight responsive foundation templates: http://foundation.zurb.com/templates.htm although you have to subscribe to foundation for downloading (I am not affiliated with them in any way). There are probably more free foundation templates to find on the web such as this really nice one: http://pixelhint.com/volcano-html5-responsive-zurb-foundation-template/ (foundation 5 is still available) Edit: make your own foundation template: http://foundation.zurb.com/sites/download.html/#customizeFoundation

My way is using two techniques. Honeypot and form filling time duration

Lowercase and normal case seemed to already be in place for those two (perhaps Ryan fixed this before I got to look at it) but just in case I added all uppercase as an option as well.

Why do you feel that it's not the way you should be doing it? The only case where I think there could be a cleaner way is if you only wanted to print a comma separated list of the titles of the items inside the Page-fields. Then you could do <h4>Course Details</h4> <strong>Level:</strong> <?= $page->course_detail_level->implode(", ", "title"); ?><br /> <strong>Category:</strong> <?= $page->course_detail_category->implode(", ", "title"); ?><br /> <strong>Grouping:</strong> <?= $page->course_detail_grouping->implode(", ", "title"); ?><br /> Otherwise, just stick with the loops

Your simplest best would be to just extend ProcessWire most basic starting point, which is Wire. This enables your class to have access to API variables (through $this), enables any of your methods to be hookable (that you precede with 3 underscores), and makes the file possible to translate with language support. Another option is to extend WireData. This is the same as Wire, except that you gain $this->set() and $this->get() methods that are accessible both in and outside of the class. It essentially means your class can function as a shared data container. The set() and get() can also be accessed by $this->key = 'value'; and $value = $this->key. The last utility class to mention would be WireArray, which is meant for storing an array of objects. This one is a little more complex than the other two (though it's still quite simple), and I'm guessing it's not what you need in this case, so won't go into detail unless you want me to. You don't necessarily have to extend any of PW's classes. But if you want $this->property; access to the API variables, you'd want to implement your own __get() method in your class: public function __get($property) { return wire($property); // or Wire::getFuel($property); }

I added this to the dev branch last week, so that you can now pass additional things to $page->render(): https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/PageRender.module#L212 One of the things I wasn't thinking about before is that $page->render() was already capable of accepting an array of options (though not commonly used, mostly internal). So we weren't starting from a blank slate, and had to make something that was compatible and complimentary to what was already there. In terms of API calls, you can now do any of these: $page->render($filename); // $filename assumed in /site/templates/ $page->render($pathname); // $pathname is full path, but must resolve somewhere in web root $page->render($options); // array of options and/or your own variables $page->render(array('foo' => 'bar')); // same as above $page->render($filename, $options); // specify filename and options/vars, etc. The $options variable was already something that $page->render() accepted before. Only it was used to specify some little-used modifiers to render(). Those are still there (and they are necessary), but now the utility of $options has been extended. When you want to specify options (outlined in the link above) you only need to specify the ones you want to change from the defaults (of course). Typically you don't need to change them, so I'm guessing that most would use $options to specify their own variables. Every rendered template now receives a copy of that $options array locally scoped. That $options array contains any variables you passed to $page->render(). It also contains PW's default options, should you want to examine any of them. If you made this render() call: echo $page->render('myfile.php', array('foo' => 'bar')); myfile.php could access the 'foo' variable like this: echo $options['foo']; // outputs "bar" One other addition that I'm thinking people might like is $options['pageStack']. That is an array containing a stack of pages that called render(). So if you are doing any recursive rendering of pages, any template can access $options['pageStack'] to see what page is rendering it, and any others before it. Previously this was not possible, and the only way a template could tell what other page was rendering it (if any) was for that renderer to tell the renderee, via $mypage->caller = $page; or something like that.