Leaderboard

Hi Alex, Had the same problem, seems like the padloper input names have changed. They are now camelcase. The specific problem comes from shippingAddressCountry. It can't find the country. $customFormFields = [ // first name [ // the name of the input of the custom form 'input_name' => 'firstName', // the input type (for sanitization) // @todo: @note: for selects and checkbox, use the expected value type 'type' => 'text', // if field/input is required 'required' => true ], // last name [ 'input_name' => 'lastName', 'type' => 'text', 'required' => true ], // email [ 'input_name' => 'email', 'type' => 'email', 'required' => true ], // address line one [ 'input_name' => 'shippingAddressLineOne', 'type' => 'text', 'required' => true ], // address line two [ 'input_name' => 'shippingAddressLineTwo', 'type' => 'text', ], // city/town [ 'input_name' => 'shippingAddressCity', 'type' => 'text', 'required' => true ], // postcode [ 'input_name' => 'shippingAddressPostalCode', 'type' => 'text', 'required' => true ], // country [ 'input_name' => 'shippingAddressCountry', // @note: country ID, hence integer! 'type' => 'integer', 'required' => true ], // region/state/province [ 'input_name' => 'shippingAddressRegion', 'type' => 'text' ], // ------------------------ // SPECIAL (NON-ALIASED) // PAYMENT TYPE/CLASS // @todo: @note: name might change! [ 'input_name' => 'padloper_order_payment_id', 'type' => 'integer', 'required' => true ], ];

https://processwire.com/store/pro-drafts/

https://www.autohaus-bendel.at/ Highlights/Features: New Logo and matching Backend using module AdminStyleRock Very good google- and performance-ratings thx to UIkit and ProCache Flexible content pages (using private module RockMatrix) Cars are fetched automatically from an austrian cardealer API and converted into ProcessWire pages with a custom filter page: https://www.autohaus-bendel.at/fahrzeuge/ Forms with honeypots and live validation (using private module RockForms based on nette forms) Web-Coach The client gets automated reminders if he does not add new content to the website. Thx @wbmnfktr Bendel Web Coach The last news entry was created 21 days ago. There must be something new that will interest your clients ;) > To the website > Create news entry Animated page transitions using barba.js Migrations and deployment using RockMigrations. Debugging using TracyDebugger. ?

PAGEGRID 1 released!

OMG you're a genius. I don't know how I missed that, but thanks. I just needed to run $child->save(); thanks

Yes indeed. Did you forget to attach the screenshots? ?. Issue is most like what @Spinbox mentioned. Hope it resolves your issue. I'll think about returning a meaningful error.

Hi @wishbone $form[email] should be $form['email'] Gideon

Just off the top of my head you might be able to get round that by having a hidden field automatically populated with a kind of concatenated version of any multi word values - maybe Alice_One and Alice_Two. That way it might be possible to treat them as single word (kind of).

the layout functionality is creating the initial page structure, but It's not creating a template with fields on the fly, if that's what you mean. The page structure is defined by the items you add to your page. PageGrid creates a hidden page for every item that gets added to it (similar to how PageTable or Repeater Matrix work). Each item is based on a block template. A template can have multiple fields to hold your data (native ProcessWire templates and fields). You can use all the fields ProcessWire provides or add even more fields using external Fieldtype modules. But you have to create these templates yourself, as well as the markup that gets rendered. If you want to get started quickly, I also developed some block modules that you can install optionally, these will create templates, fields as well as a template files automatically, without the need to write any code. These blocks will cover the basic needs for most websites (containers, text, images, video, slider, maps, etc..). More information and documentation is coming soon. Until then have a look at the first post ?

@Robin S I can confirm that this works really well. it's a relief, honestly - I expected having to dive deep int sql for this. One thing that doesn't seem to work is to match things in quotations "Alice One" and "Alice Two" will both be considered related because of the same first name "Alice", regardless of quotes or not. But that's fine in my case.

Perfect! And thanks again for your module and these changes / helper

Thanks @kongondo for clarification and the swift update. I’ll print this out and put it on my wall ?

Hi @Jan Fromm, Thanks for reporting this. Nope. Entirely my silly mistake. Nothing to do with your setup or Tracy ?. Forgot a 'check_access=0' in the selector to grab the line item to delete (since they are in admin). So, the reason it worked with 'Tracy enabled' is, I guess, you were logged in as a Superuser :-). Anyway, sorted for now. Please grab the updated files again. Not at all ?. Thanks.

The labels are settings/properties of InputfieldSelectImages so you would need to customise them there rather than via FieldtypeDynamicOptions. You'd use a hook like this: $wire->addHookAfter('InputfieldSelectImages::renderReadyHook', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; $page = $inputfield->hasPage; // Some test here using $inputfield/$field/$page $inputfield->label_unavailable = 'This is my custom label.'; }); The styling is based on the core InputfieldImage, and rightly or wrongly the equivalent icon there is centered within the button, excluding the thumbnail border. So I don't want to change from that generally. But now that the icon has been changed to a cross instead of the earlier trash icon it does look like it could come up a couple of pixels so I've done that. Of course you can always tweak the styling to your liking with custom CSS as you're doing. Done.

I am still working on this one. It works great and is quite flexible now. I made a couple of improvements. Now the data to style the items is stored directly on the item with $page->meta(). This way, cloning pages and page reference fields work out of the box. Also there is no need for hidden fields anymore. The style panel now supports adding custom classes and assigning styles to them. These classes can be used globally on all pages (a css class is also a page). The style panel now supports selecting html tags to style tags globally across the whole site. I did a lot of refactoring to make the code cleaner and more efficient. There are still things where I am looking for feedback before releasing an open beta for this module: Sharing blocks and migrating pages I played with the core ProcessPagesExportImport and the migrator module and it seems that it's not exporting the meta() data, which is a bummer. So for now I might not be able to have a migration feature out of the box. Maybe someone else can take a look at this, but it seems to be too much hassle for me now. Importing/exporting the whole database with ProcessDatabaseBackups works as expected though. Also I did develop some block modules that you can install optionally, these will create the needed templates and fields for that block and give you a quick way to start working with PageGrid (without the need to create your own templates or install a site profile), more on that later. (Item pages are based on a block template). Structure of PageGrid items/pages I decided to always store the items under the admin page in a seperate parent, instead of making the parent customisable (like PageTable is doing). So there is a clear separation between pages for your site and item pages. PageGrid then creates a structure looking like this (makes it easy to access the pages): Admin – PageGrid Items – Home items (name: for-1213) – Item Editor – Item XY – Another Page items (name: for-1315) – Item Group – Item XY – Item XY – Item Editor The structure of these pages is an exact representation of the PageGrid items/pages (sorting, child/parent relation, hidden/published). While working with PageGrid via the UI this is not so important, but I think it will make interacting with the item pages via API more flexible and clean. Adding a page to any of the item pages via API or the backend also adds the page to PageGrid. If you delete a page containing a PageGrid field, the items also get deleted. You can also sort via API (or manually under the Admin page) and the changes are reflected for the items as well. The connection is via a name like for-1213, where 1213 is the ID of the page holding the PageGrid field (inspired by repeaters). I like this setup because it gives you a lot of options to access items via API and keeps the pagetree clean. Also it will make it easier to handle migrations for pages containing a PageGrid field in the future (just import/export the page and the item page container). One downside, though, is that the methods of PageTable like $page->pt->add($newpage) or $page->pt->remove($newpage) are no longer working (PageTable is using a PageArray that is saved as the field value). Also this will not work with multiple PagGrid fields on one page (A PageGrid field can however have a page reference field to another page containing a PageGrid field, as well as having nested pages, so I see no benefit of supporting multiple fields). You can add a page to the item parent like this: // Add an PageGrid item via API $itemParent = $pages->get("for-$page->id"); $itemParent->add($newpage) I am not decided if my approach is better or if I should just stick with the PageTable methods (keeping the items stored as PageArray inside the field). Since PageTable can only have one parent that you select in the field settings, all items will than be stored under the same parent, which is a bit messy. Not sure if any of that makes sense to you ? Any feedback is welcome. More info and website is coming soon!

I have watched a number of critical reviews about Co-Pilot on YT and I am not so sure anymore if the future looks bright.

I know this is not exactly what you were asking for, and it's based on an older version of PrivacyWire so there may be an easier way to do it now, but here's how I handled a similar need (just in case it's of use to you or someone else here): <script> window.cookieConsentUpdate = function(do_update) { do_update = typeof do_update === 'boolean' ? do_update : true; let privacywire_data = window.localStorage.getItem('privacywire') ? JSON.parse(window.localStorage.getItem('privacywire')) : ''; window.cookie_consent = { 'necessary': privacywire_data ? (Boolean(privacywire_data.necessary) ?? true) : true, 'functional': Boolean(privacywire_data.functional) ?? false, 'statistics': Boolean(privacywire_data.statistics) ?? false, 'marketing': Boolean(privacywire_data.marketing) ?? false, 'external_media': Boolean(privacywire_data.external_media) ?? false }; if (do_update) { // this is where you could send data to GA etc. } } window.cookieConsentUpdate(false); </script> Now just have this function run when cookie settings are changed; do_update will default to true, and any custom code in the if block will be triggered.

So it is ublock-origin. Thank you for the pointer - I should have checked that first! Updated to add 1: I actually run UBO in all my browsers so there must be a settings difference between UBO in my FF and Brave installs - will look into it. Updated to add 2: Found it in case anyone else is interested. There's an entry in the UBO blocklist called "Fanboy's Annoyance" for .privacywire-wrapper that is causing the issue. I had this list enabled in FF but not in chrome.

I just released a new extension module AppApiPage (waits for approval), which handles the initial steps from my post above completely automatic. You install AppApi and AppApiPage. That makes the /api/page route available and you only have to add the code on top of your template php to add a custom JSON output to your pages. <?php // Check if AppApi is available: if (wire('modules')->isInstalled('AppApi')) { $module = $this->wire('modules')->get('AppApi'); // Check if page was called via AppApi if($module->isApiCall()){ // Output id & name of current page $output = [ 'id' => wire('page')->id, 'name' => wire('page')->name ]; // sendResponse will automatically convert $output to a JSON-string: AppApi::sendResponse(200, $output); } } // Here continue with your HTML-output logic... I hope that this makes it even simpler to add a full-blown JSON api to new and existing pages.

I stumbled upon another issue: a.f.a.i.k. the IMPRINT and PRIVACY pages should not be covered by this modal. Otherwise, you cannot read what you are going to decide (if you followed the privacy link in the module, for example). But I am not a lawyer, it is just how I think it should work logically, especially thinking of the very strict German laws about the IMPRINT page accessibility. - Any oppinion? I am looking for an easy way. Right now, I am using CSS to hide .privacywire and its wrapper on those. But since the links to those pages are stored in the modules settings, why not excluding them automatically? Just an idea. In this context, it would be cool if the module did some quick checks to assist the webmaster if those linked pages actually exist and are viewable.

I just added some new features. – All blocks can be cloned now. Which makes adding content very fast – More options to control access of blocks individually. You can lock editing of blocks completely or disable features such as cloning, styling or content editing for certain roles I was also thinking about the best approach to copy blocks between PW installations or to share them with others. The easiest way I found was to export/import a page, with all the blocks you want added, using adrians migrator module. The export code together with the block template files could be shared with others or imported into existing installations. So this would be an option until we hopefully have something in the core to make migrations work better. An alternative would be to store everything as JSON (including the content) and using something similar to the Mystique Module to let the developer add fields based on config files. That also has the benefit of being able to have the files version controlled. The downside of using the JSON only approach would be inferior searchability of fields. Also making it work with every fieldtype would be a challenge. I'm interested how others feel about this.

Actually, it's pretty nice running your API call through the Tracy Console - save it as a snippet so you always have it on hand. This way you can easily see the results of the selector as well as the SQL query used to generate them. PS I think this is the thread that was mentioned regarding teppo's version: https://processwire.com/talk/topic/9408-is-there-a-way-to-convert-a-selector-in-sql-using-pw-engine/ although I think it's actually longer.