Leaderboard

Autojoin is a flag, like system, global, etc: $field->flags = Field::flagAutojoin; $field->save();

Hi, it look like you are looking for that: https://processwire.com/blog/posts/processwire-2.5.2/#new-wirerenderfile-and-wireincludefile-functions

Go to "edit template", select tab "advanced" and you'll see a settings section that looks like this:

Some loosely related observations re PWA vs. native:

PhpStorm doesn't know what API variables PW makes available to template files. So you need to add variable types hints in a DocBlock at the top of your template files. I use... /** * @var Config $config * @var Fieldgroups $fieldgroups * @var Fields $fields * @var Languages $languages * @var Modules $modules * @var Page $page * @var Pages $pages * @var Paths $urls * @var Permissions $permissions * @var ProcessWire $wire * @var Roles $roles * @var Sanitizer $sanitizer * @var Session $session * @var Templates $templates * @var User $user * @var Users $users * @var WireCache $cache * @var WireDatabasePDO $database * @var WireDateTime $datetime * @var WireFileTools $files * @var WireInput $input * @var WireLog $log * @var WireMail $mail * @var \ProCache $procache * @var \FormBuilder $forms **/ Your field names are not a part of the PW API (field names don't exist in the file system but only in the database). But I believe you can get code completion for field names using the Template Stubs module.

You don't even need to do that If you have the Request Info panel running, you will see the POST variables automatically populated - depending on your scenario it might be in the main bar, or the "redirect" bar.,

https://www.websprudel.de/processwire-ein-cms-das-sich-anzuschauen-lohnt/

Just pushed a fix for this issue to the 2.0 branch

Yes: http://modules.processwire.com/modules/connect-page-fields/

I wasn't sure but after checking I can say that AOS supports additional fields added by Image Extra module

I have tried to use front-end editing using the <edit> tags. It seems, that I always get the history tab below the fields I am editing even though those fields are not under version control. Is there any option not to show the history tab with front-end editing modals?

Hi, I have created a site profile that shows how to integrate ProcessWire 3.0 with Vue 2.0. See repository here. How this site profile works This ProcessWire site profile is loosely based on the REST API tutorial by @gebeer. Here are the most important steps to reproduce it: Admin settings Create an api template with default settings and just the title field assigned to it. Refer to @gebeer tutorial for further details Create a pages and nav templates with just the title field, for both template tick “Allow URL Segments” in the “URLs” tab (see attachment) Create a home template, this is going to be the single php file that will load your Vue SPA. Assign this template to the root of your website Any other template you create should have the “Alternate Template Filename” field in the “Files” tab set as home (see attachment), in this way if a user enter the website from any url that is not the root, ProcessWire will always redirect to the home template, Vue router will handle the url and call the right data through the REST API Under the root, create an api page and assign the api template to it (you can set “hidden” to this page so doesn't show up in the menu) Under the api page, create the pages nav and pages (see attachment), and assign the templates nav and pages to them. Now you have the www.sitename.com/api/pages and www.sitename.com/api/nav urls that you can use to fetch the JSON data PHP template setup In the templates folder, create home.php file and leave it empty, the HTML will be generated by webpack Now create pages.php and nav.php files. On these files is where we return the JSON data, based on the right url segment. Again, refer to @gebeer tutorial for further details on this matter. Note that I wrote a PageFields class that I use on these templates to fetch ProcessWire fields. The fields that are supported are text, textarea, repeater, img. Other fields may work but I haven't tested them. See the REST API setup for further details about how to use the PageFields class REST API setup You can decide what fields are included and what fields are excluded by passing a configuration array to the PageFields class. You can find here a list of the available configuration settings. See examples below. Show only selected core fields: $pageFields = new PageFields($p, [ 'fld_core_included' => ['url', 'httpUrl', 'template'] ]); Show no global fields, and only selected custom fields: $pageFields = new PageFields($p, [ 'fld_core_included' => [], 'fld_include_all' => false, 'fld_included' => ['title', 'gallery'], ]); On a gallery image field, hide breakpoint listing and show only httpUrl field: $pageFields = new PageFields($p, [ 'img_fld_overrides' => [ 'gallery' => [ 'fields' => ['httpUrl'], 'bp_list' => false ] ], ]); Webpack setup The most important file of all Webpack setup is config/index.js. On line 33 you need to provide your domain name so that Webpack can proxy the ProcessWire REST API to the Webpack dev server. Without this you wouldn't be able to take advandage of the Webpack hot module replacement feature which allows you to reload a vue module without refreshing the page, it also allows you to keep the state of the app. Notes My REST API may have bugs, this is just an example of an integration with ProcessWire, I suggest you either build your own REST API or use the awesome GraphQL module by @Nurguly Ashyrov. Todo Replace REST API with the GraphQL module. This requires vue-apollo, the Apollo/GraphQL integration with Vue, and vue-supply for integration with Vuex.

Sometimes you need to track changes in certain values of a page to take an action afterwards. In this example I will show you how to show a simple message after changes to inform the user that field values have been changed. Put this piece of code inside your ready.php. //Track changes $pages->addHookAfter('saveReady', function($event) { $page = $event->arguments[0]; if(!in_array($page->template->name, array('template1','template2'))) return; $fields = array('field1','field2','field3','field4'); $changedfieldsarray = array(); foreach($fields as $field) { if ($page->isChanged($field)) { $changedfieldsarray[] = $page->fields->get($field, true)->label; } } $fieldnames = implode(", ", $changedfieldsarray); $this->warning(sprintf(__("Following fields have been changed: %s"), $fieldnames )); }); The first restriction in this example is to run this hook "aftersaveReady" and only on certain templates: in this case template1 and template 2. You need to rename this to your template names. Remove the following line of code if you want it to run on all pages (no restrictions): if(!in_array($page->template->name, array('template1','template2'))) return; Now you have to define the fields where you want to track changes (take a look at this line): $fields = array('field1','field2','field3','field4'); In this case the fields are called "field1 to field4". Rename it to your field names. The API call to track changes is "$page->isChanged('fieldname')". You will find more information at https://processwire.com/api/ref/page/is-changed/. Use a foreach to loop through the fields array and store all changed fields inside an array. In the last step all the changed fields were outputted inside a message to inform the user. In this case I want to show the labels instead of the field names. Only to mention: The changes will keep alive, so you have to delete it manually (http://cheatsheet.processwire.com/pagearray-wirearray/change-tracking/a-resettrackchanges/). This little tutorial should only be a starting point for your own coding.

Here is a new created version to track changes which works without any problems and you dont have to take care about the deletion of input values if the page was not saved successfully (like in the version before) Put this little piece of code inside your ready.php. //Compare before and after values and output a warning message $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); $page->of(false); //configuration: change it to your needs $templates = ['event_businessvacations', 'event_dates', 'event_events', 'event_specialbusinesshours']; //array of templates where this hook should run $fields = ['summary', 'body']; //array of fields which should be checked //configuration end if(in_array($page->template->name, $templates)){ $changedfields = []; foreach($fields as $fieldname){ if ($page->isChanged($fieldname)) { // Page as it is in the DB $oldPage = wire('pages')->getById($page->id, array( 'cache' => false, // don't let it write to cache 'getFromCache' => false, // don't let it read from cache 'getOne' => true, // return a Page instead of a PageArray )); $changedfields[] = $oldPage->fields->$fieldname->label; } } $changedfields = implode(", ", $changedfields); if(!empty($changedfields)){ $this->warning(__("The following fields have been changed: {$changedfields}")); } } }); Change the configuration block to your needs (template names, field names). This little code snippet outputs only a warning message which fields have been changed - not more or less, but you can also run some other logics - its up to you. Note: Works also with repeaterfields, but you can only check the repeaterfields for changes in general. It is not possible to check for specific fields inside the repeater.

this comes from time to time since PW 2.3

Thank you! That´s it!

Works a treat. Just the fact, that the two tables in the database are redundant, is a bit sub optimal. I guess it is because of how the page field works? But I can live with that. Thank you.

Thanks for letting me know. That makes sense: the page level snapshot feature makes use of timestamps, so timezone settings being off could make it misbehave. Field level features work just based on revision IDs, so this issue wouldn't affect them I should probably add a note about this somewhere..

PS - don't forget ->each("title") when testing page selectors so it's easier to see what pages are matched.

No, a form doesn't work that way. The way you have it set up now you have a single form with multiple submit buttons. It doesn't matter which submit button you click, the submitted form data will be the same. The thing is that the name of each post variable is determined by the name of the input element it corresponds to. Where you have multiple inputs with the same name (which you will have unless you rename them using something like what I suggested before) only the last input of each name will actually make it into post. Although you could change to having multiple forms (one for each grandchild page) I don't think the idea of multiple submit buttons is a good one. Where users see multiple fields from multiple pages in the same module interface the expectation will be that they can edit all of these fields at once. But in fact all changes they make besides those inside the form they click the submit button for will be lost. Users might not notice that which could cause problems, or they might notice it and report it to you as a bug. You don't really want either of those. A single form with a single submit button would be better, then you loop through the submitted form data and use the added page ID prefix to connect it to the relevant page. But remember you need to sanitize all the submitted data. It looks like you're sort of recreating ProcessPageEdit with your module here - have a look at ProcessPageEdit::processInput to get an idea of the kinds of things to look out for. If the action of your form points to your Process module page (which it will do by default unless you changed it) then all the post data will be accessible in the init() method of your module, as you are already trying. But as I said above, the array of data is in $this->input->post. You mentioned you have Tracy installed - so do... bd($this->input->post); ...in your init() method and you will see the post data you have available.

https://thesmartgroup.ie/ We launched this earlier in the year, I'm only just getting round to sharing it. This is the 4th iteration design wise in the past 5 years and personally my favourite in terms of design. The old site was PW based so we had a lot of the content in there but undertook a major re-write and claw back to make everything cleaner and more succinct - relying on more visuals to promote the work we do rather than verbose copy. The site is not using anything out of the ordinary, just standard modules I tend to use for all PW sites: AIOM SEO Markup Sitemap XML AutoSmush MenuBuilder: Markup The site loads pretty darn quick considering it's using a lot of images and many of them are 96DPI for better display on Retina.

I think that integrity constraint violation definitely needs attention! But back to the issue at hand - have you tried using Tracy in Production mode to log the errors. When she emails, she only sends one until you clear the sent email flag, so your inbox won't be bombarded with repeat errors. Tracy also has Slack and Monolog adapters: https://componette.com/search/tracy available, but I guess it wouldn't be hard to write a Jira one if you prefer that.

Maybe setup some simple rules with Zapier or IFTTT? Perhaps even post automated tickets to JIRA or some similar app? btw, the same error appeared earlier in the forums:

Tried with FieldtypeMatrix; Works like a charm. Great addition for our intern site-search-functions!

Thanks Teppo, looks great! The bugs I reported earlier were not fixed on these updates. That make me look more careful the server setup and the issue was that PW timezone was not the same that server was using - that caused history tab to work inproperly. Interesting thing is that the field specific compare/restore did work nicely even on bad configuration.

That's awesome news! A few quick questions though: Can these new find methods also be used with findMany() and $pages->findIDs() ? Can I use this with Pro Fields as well? e.g. if I have a text field in a Matrix Repeater, will these be also considered?

Here's a document I've been working on https://docs.google.com/document/d/1peY-FUpevKgy87cKOxIVz8jwcv2-3c61zbiJr3QKO6c/edit?pli=1# Flexible Page Layouts in Processwire. It's still rough, but I've been using it to help collect all my thoughts/notes on all the ways to achieve flexible layouts in Processwire. I love hearing about other ways people are structuring their websites. Here is another document that helps me wrap my head around some of the different field types in Processwire. (all on one page) https://docs.google.com/document/d/1VcSluQyjl9AhMBcJA3R4-uZb9IUYdKXGSh7Phclf34Y/edit?pli=1#heading=h.ysvx3k7ssuw7 Hope it helps someone.

Here we go .. The basic idea is an textarea fieldtype with a function somewhat similar to an website blocks builder, I know that currently this can be achieved using a Repeater, Repeater Matrix or Hanna Code, but perhaps this way would be easier for the developer/user and more flexible. The idea came after seeing this plug-in: https://formbuilder.online/ ... and the implementation could be based on these modules: https://github.com/blynx/TextformatterFunkyFunctions from @blynx https://github.com/outflux3/SettingsFactory from @Macrura https://github.com/Toutouwai/HannaCodeDialog from @Robin S Based on TextformatterFunkyFunctions we would have a folder for this type of field with the design blocks that we want to make available to the user: These block files would have main three sections: The Settings section for the Block UI could be based on the SettingsFactory code. A mockup of the user interface of the field would be: It would have drag and drop to add and sort the blocks, and display the generated Form by each block in order to enter the block data The field will have three display modes in the backend: BUILD - the first where field content is configured in visual and interactive mode: CODE - The second is the "real" configuration of the field as required by TextformatterFunkyFunctions and is the data that is stored in the Processwire DB. This mode could be hidden for some users: PREVIEW - The third one is the visualization of the field output, it could be done using Ajax requests to the module into an iframe or inserting the response in a DIV using jquery. Maybe some code of this module will work: http://modules.processwire.com/modules/fieldtype-runtime-markup/ from @kongondo I hope that I have been able to explain the idea correctly, but I can not wait for it to be inspired to make a perfect explanation, .. waiting for that moment and it has been in my trunk for a long time .. It's just an idea to debate, maybe it will be an inspiration for other things, or for someone who wants to develop it (as a commercial module or not)

So at least we have more than 8800 sites using Processwire https://publicwww.com/websites/"X-Powered-By%3A+ProcessWire"/ @jmartsch take a look at this link

Hi, me again - queen of the ProcessWire API Wrapper. Why re-invent the wheel when there are so many great, well-supported apps out there that don't impact on the core of PW? Almost see PW as a portal. Latest endeavour is a PW module for Eventbrite v3 API https://www.eventbrite.com/developer/v3/ The EB webhooks are a easy-peasy-lemon-squeezy. Love it! Can do any of the API GET calls providing they don't include any parameters, eg: $eb = $modules('EventbriteAPI')->login(); $ebUser = $eb->client->get('/users/me/'); $ebUserId = $ebUser['id']; // /users/:id/owned_events/ $result = $eb->get("/users/$ebUserId/owned_events"); Problem I'm having is with using parameters in the actual API, eg: $eb = $modules('EventbriteAPI')->login(); $ebUser = $eb->client->get('/users/me/'); $ebUserId = $ebUser['id']; $ebPath = "/users/$ebUserId"; $token = $sanitizer->text($eb->access_code); $pageSize = $sanitizer->int(5); $expand = array(); $result = $eb->client->get( $ebPath . "/events?&token=" . $eb->access_code . "&page_size=" . $pageSize ); Every time I use a parameter, I get the EB error message for the last one, in the example below, the paging limit: "There are errors with your arguments: page_size - Enter a whole number." Even stranger is if I manually create the URL, eg https://www.eventbriteapi.com/v3/users/2425020999999/events?&token=WNU7SPIEUUUIXXXXXX&page_size=5 in the EB API test environment, I get the correct result. Fairly certain it's an EB issue but wanting to double check I've got everything right and the PW API isn't doing anything too clever with the $_GET vars. Any help/suggestions most welcome. Thanks psy

It's been out for about 10 days now, but I never really announced the changes here - wanted to see if there were any issues before publicizing. The new 4.9.x version is now available. Here's a list of the main changes: 1) New File Editor Panel Supports editing all files in your PW install (you can define the root as /, /site, or /site/templates Can be used as the handler for opening editor links from the debug bar (errors, log files, Captain Hook, ToDo, Template editor, etc), rather than your code editor. Can be enabled as the link handler for live sites only, or local as well if you prefer. Has "Test" functionality for all files so if you make a change, it will only appear for you and not other users. Makes a backup of the old version each time you save a change and provides a "Restore Backup" button to instantly revert. Supports in-code search & replace with CMD+F Syntax highlighting/linting for PHP, CSS, and JS This replaces the Template Editor panel, so that one has been removed. Handles fatal errors gracefully - this is the biggest feature in my opinion. The problem with most online file editors is that if you accidentally make a code change that results in a fatal error, it can be impossible to fix and resave because the system is not functional. This editor gets around this problem by using Tracy's custom error handling which allows debug bar panels to continue to work, so you can manually fix the problem, or click the "Restore Backup" button. Of course if you used the "Test" option, you don't even need to worry, because you are the only one to see the version with the error anyway. As a follow up to that last point. I have used the excellent ProcessFileEdit module for helping to debug some issues on other people's sites without needing FTP access, but a couple of times I have made a fatal error mistake and had to get them to restore the file, so this really is a huge feature for me! 2) Support for Process File Edit If you prefer ProcessFileEdit to this new File Editor Panel, so you can use it for handling debug bar links. Note that this won't give you the "Test" and "Restore" options, or the fatal error protection, so it's not really recommended. I added support for it before building the File Editor panel so decided to leave in case others prefer it. 3) Revamped Console Panel The code and results sections are now a "split" screen so you can adjust the size of one relative to the other with the bar in the middle. Handy for working, but especially handy when you want to post a screenshot to the forums "Large and "Small" versions of the panel - click the arrows at the top right of the panel - the large version can be very handy when you have lots of code or results to display Supports in-code search & replace with CMD+F 4) New maxDepth and maxLength shortcuts and new barDumpBig() method You can now replace dump or barDump calls like: bd($var, array('maxDepth' => 7, 'maxLength' => 500)); with: bd($var, [7,500]); You can also make use of the new: bdb($var); as a shortcut to: bd($var, [6,999]); 5) New SQL Query column in the Selector Queries section of the Debug Mode panel This is a great learning tool to see the selector queries that are run for a given page request, and what SQL query these selectors are translated into: 6) Removed old Legacy version of Tracy core It was getting too painful to maintain support for this old version. This means that TD now requires PHP 5.4.4+ 7) Namespacing and refactoring lots of Javascript code No feature changes, but code is now easier to follow and is much less prone to any name conflicts with your site 8) Reduced loading of unnecessary code Lots of refactoring here too - should see some performance gains 9) New default server type indicator in the debug bar Not a big deal, but if you want a server type indicator and don't want the full height/width bar, you can now have one in the debug bar - I think it's a handy visual clue when looking at /working on live vs dev/test versions of a site at the same time. 10) Lots and lots of bugs fixes, layout, and styling improvements It's amazing what you find when you're buried in the code for a couple of weeks solid 11) The new docs site that I mentioned earlier is now fairly complete - I just need to work on the Tips & Tricks section https://adrianbj.github.io/TracyDebugger Feel free to make a PR for improvements to the docs - everything is under the /docs folder in the main Github repo. There are also "Edit on github" links on each page so you can use those as well.

See if this helps: https://processwire.com/talk/topic/17089-images-disapear-after-uploading-and-saving/?do=findComment&comment=150139

got some very good news on this (it feels like christmas for myself, because this made me some headache over the last months and the solution is quite simple and solves a lot of problems). I did some performance tests on a table with more than 10.000 rows and got the following results here on my local test environment (laragon + i7 @ 2ghz). rendering the table with javascript test-data works instantly (using deferrender option, did not try without) rendering the table with data coming from pw pages and 5 different fields takes around 16s single-language setup without caching takes around 5s to load multi-language setup without caching around 8s with markup cache enabled 180ms the screenshot shows a multi language table with 10.000 rows and 12 fields that loaded in 9,1s when building the cache. thats some really nice results, because it will make the setup even easier and it will even work with multilanguage wich I didn't know how to tackle before. my goal always was to stay on the client side, because there you have all the power of datatables: you have a powerful API to filter, sort etc the table and this plays perfectly well together with other clientside libraries like chart.js; my testcase showed that the search and sorting was also very snappy so I think it's definitely doable! It will be the first project after my master thesis and I may have something ready around 03/2018 I don't think that's a proper way to do this. I think there are only the 2 options: Release it for free (donations are always possible and welcome of course) without any support, documentation etc. or release it as pro module and provide proper support and docs. maybe @kongondo or @apeisa can share some of their experiences with us (or at least with me in a PM)?

glad you like it and thanks for the compliment yeah... it's not as easy to find in the beginning (and often i'm still searching a lot around the code). but most of the necessary informations are not too hard to find if you look at the code. Inputfields for example have a baseclass here: https://github.com/processwire/processwire/blob/master/wire/core/Inputfield.php Also see somas tutorial about forms (i updated my initial post with the link: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ ) I'll see what i can do...

Hi HarryPhone, sounds like you are just a little too early. Your usecase looks like a perfect fit for my new modules agree with this, would do it a little different though: i would use my RockDatatables instead of the Core AdminDataTable. you will be much quicker and you will have much more options regarding rendering the table (coloring cells, rendering linked icons and the like). regarding the import you have serveral options (there are several csv modules around). it's also very easy to write your own XML importer: using my module you can build highly customized listers. its also very easy to create processmodules to make them available as single pages in the pw admin. the module is not released yet and has some drawbacks (like mobile usage or handling large datasets is not yet implemented, that would be a case for regular listers), but maybe it's interesting to know that something like this is coming up.

Absolutely. Nowadays we build most of the stuff in the back-end with custom Process modules in combined with the forms api. Importing content is also pretty easy. You might ask why not in the front-end? Because the roles and permissions work flawlessly in the backend and the back-end looks pretty good (Reno looks imo the best), but you can create your own based on Uikit. If you want to overwrite the default styling take a look at AdminCustomFiles where you load css and javascript files. Also take a look at MarkupAdminDataTable since most of the stuff you will need is forms and tables. This makes it pretty easy to prototype.

Jens, You can achieve this with the help of $config->httpHost. For this to work, your two domains should be bound to the directory where your PW installation resides. Then, in your template, you can check which domain name is used, and serve your users relevant content. Example: if ($config->httpHost == "www.example.com") { echo "You are visiting example.com. Have some content of type A."; } elseif ($config->httpHost == "www.example.org") { echo "Looks like you are visiting example.org. You get some content of type B."; } Also, to bind your users to a specific domain, you can add a field for a user profile and keep their domain name in it so you redirect your users to the right address.

Actually PHP is what the comments system uses for sending email. And it doesn't get any simpler: <?php mail("you@company.com", "Subject", "E-Mail Body"); If you want to send HTML: <?php mail("you@company.com", "Subject", "HTML Content", "Content-Type: text/html"); If you want to include a specific FROM address: <?php mail("you@company.com", "Subject", "HTML Content", "From: bob@company.com"); If you want to do both: <?php mail("you@company.com", "Subject", "E-Mail Body", "From: bob@company.com\nContent-Type: text/html");