Leaderboard

Nice play on words there. -- In the article you mentioned you could modify your tables to InnoDB by exporting, doing a search/replace, then re-importing. You can also do it like this: <?php namespace ProcessWire; // assuming this script is in the pw root dir; backup your database first, just incase! include(dirname(__FILE__).'/index.php'); $query = $database->query("SELECT table_name FROM information_schema.tables WHERE table_schema='{$config->dbName}';"); foreach($query->fetchAll() as $row) { $table = $row[0]; $database->query("ALTER TABLE $table ENGINE=InnoDB;"); }

Because it is simply amazing, has an improved user experience, is more lightweight, better looking and has nicer features than version 4. Almost everybody will profit. Please consider voting at github for this feature: https://github.com/processwire/processwire-requests/issues/217

This week we take a look at a couple of reasons why you might want to choose InnoDB as your MySQL database engine when installing ProcessWire— https://processwire.com/blog/posts/using-innodb-with-processwire/

@Jonathan Lahijani That snippet changes the engine for tables, but there are other things need to be changed of InnoDB when using utf8mb4: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/install.php#L958-L969

Hello for all, ConfigurationForm fieldtype module is one my experiment from 2016. Main target to build this module was to store multiple setup and configuration values in just 1 field and avoid to use 1 db table to store just single "number of items on page", or another db table to store "layout type" etc. Thanks to JSON formatted storage this module can help you to reduce number of PW native fields in project, save DB space, and reduce number of queries at front-end. Install and setup: Download (at the bottom ), unzip and install like any other PW module (site/modules/...). Create some filed using this type of field (ConfigurationForm Fieldtype) Go to field setup Input tab and drag some subfields to container area (demo). Set "Name" and other params for subfields Save and place field to templates ("Action tab") How to use it: In my case, I use it to store setup and configurations values, but also for contact details, small content blocks... (eg. "widgets"). Basic usage example: ConfigForm fieldtype "setup" has subfields: "limit", type select, option values: 5, 10, 15, 20 "sort", type select, option values: "-date", "date", "-sort", "sort" // get page children (items) $limit = isset($page->setup->limit) ? $page->setup->limit : 10; $sort = isset($page->setup->sort) ? $page->setup->sort : '-sort'; $items = $page->children("limit=$limit, sort=$sort"); Screenshots: Notes: Provide option to search inside subfields Provide multilanguage inputs for text and textarea field types Provide option for different field layout per-template basis Do not place/use field type "Button" or "File input" because it won't works. Please read README file for more details and examples Module use JSON format to store values. Text and textarea field types are multilanguage compatible, but please note that main target for this module was to store setup values and small content blocks and save DB space. Search part inside JSON is still a relatively new in MySQL (>=5.77) and that's on you how and for what to use this module. Thanks: Initial point for this fieldtype was jQuery plugin FormBuiled and thanks to Kevin Chappel for this plugin. In field type "link" I use javascript part from @marcostoll module and thanks to him for that part. Download: FieldtypeConfigForm.zip Edit: 14. August 2018. please delete/uninstall previously downloaded zip Regards.

It is a little messy since I have not set the template families perfectly yet, and normalized the template name case, but this should give you an idea of how it flows so far. I add a banner slide to the homepage, add a new basic page, and add a few sections to that basic page. The basic page layout is what adds the inner page title row. That's the only item I have added to that since the nav is marked sitewide. I then add the test content to the page itself under a content item which allows the uikit items. I could have added it to the page layout, but it would have gone to everything marked as a basic page.

May I suggest to simply exclude button and file inputs - it's kinda pointless to see them there as available input fields, when in fact they don't (yet?) work. And the mulitlanguage part would be really really awesome. Most sites we build are multilang, so this feature would be almost a must-have, rather than a nice-to-have. Did you post your module to the official PW module directory? https://modules.processwire.com/add/ That way, it would be easier for other people to find your module. And (afaik) this is a pre-requisite if you want people to use the "check for updates" feature in the PW-backend. Zelim ti lep vikend ?

The second-last example explains it quite well: // generate breadcrumb trail that includes current page foreach($page->parents->and($page) as $item) { echo "<a href='$item->url'>$item->title</a> / "; }

@ryan Seems like you've been addressing my personal wish-list recently - 2FA and InnoDB - I've been an advocate for both for a long time. Thank you!

New website design for HealthCARE Express. Used UIkit3 for the front end look. Jquery Store locator for the locations page. PW Modules used: Hanna code, google map marker, Inputfield Ace Extended, MarkInPageTree, Video embed for YouTube/Vimeo, and an in house asset minification module. Backend is pretty unique. Basically, I use the processwire templates for UIKit items instead of pages. ie. card.php, container.php, section.php. navbar.php, grid.php, slideshow.php. I also add some extra things like page.php, inner_page_heading.php, image.php, page_snippet.php, text.php. (Page snippet is if I want to run php.) Most of the root pages in the admin page tree use the page.php template. Their children are either detail pages or layout rows for that page. I also have a blog.php that uses the page.php file, just because that lets me force the children to be blog posts. The page and blog templates have fields like meta page title, meta page description, selected page layout, css, js, images, files. All markup is added through admin as well through things like the selected page layout. I have one page in my page tree for page layouts and I add children for the markup. ie. I can add a "Service" page layout to the backend, and add a "page heading" child, an intro "section" child, a service "grid" child, etc. You can check out screenshots. It basically gives me a page builder! The children of the grid page are forced to be cells, and have gui to select the columns and such. I have a css field and a js field attached to almost everything. On page save, if that page has one, it pulls them all and merges them all into one css file and saves it to the server with a timestamp as filename. That way all php, css, and js code is done through backend.

I have found that InnoDB performs badly when importing pages via CSV. I really should have tested this 1,5 years ago when @adrian suggested it (I guess I needed a rest). All the other testers back in 2017 obviously used MyISAM as their import results were so performant. My results from today: MyISAM: 30729 pages imported, 120 s timeout (actual time 4 min 42 s) InnoDB: 7232 pages imported, 120 s timeout (actual time 9 min 10 s) Used a stopwatch for the actual time. Machine is i7-6700K, 32GB memory, SSD. Dev environment running under Docker. PW 3.0.98. DB charset utf8mb4. PHP Version 7.2.5 Batch Child Editor used for importing. Test case included as attachment. It has importable JSON for fields and the template and a CSV file. CSV is tab separated and all fields are enclosed with the character ^ My MySQL cnf override is: [mysqld] innodb_buffer_pool_size = 16G # (adjust value here, 50%-70% of total RAM) innodb_log_file_size = 256M innodb_flush_log_at_trx_commit = 1 # may change to 2 or 0 innodb_flush_method = O_DIRECT innodb_file_per_table=ON innodb_stats_on_metadata = OFF innodb_buffer_pool_instances = 8 # (or 1 if innodb_buffer_pool_size < 1GB) query_cache_type = 0 query_cache_size = 0 innodb_autoinc_lock_mode = 2 innodb_io_capacity_max=6000 innodb_io_capacity=3000 key_buffer_size = 1024M max_allowed_packet = 1024M table_open_cache = 2000 It seems to me we can't affect the performance by simply tweaking InnoDB settings. I assume PW would need core changes to adapt to InnoDB here. Pinging @ryan I did some digging and ran into an article, which details the bugginess of InnoDB FULLTEXT indexes. I went through the list of bugs and only a couple were fixed (some were closed as wontfix). Kind of depressing ? csv-testcase.zip

We recently finished a relaunch of the website of the consulting firm Engfer Consulting: engfer-consulting.de. Built with ProcessWire 3 and Bootstrap 4. Features Bilingual website (UPDATE: The English page is now available! the English page is inactive at the moment, as the content is not ready yet) A strong, simple data structure for job offers and news, allowing for a custom search page and fulltext search Sectioned content-blocks built with a Repeater Matrix (ProFields) Reusable components available as page reference fields Automatic generation of open graph-tags, with manual overrides available on each page Contact forms with a custom recipient depending on the current page Modules used: ProFields ProForms Sitemap Cookie Management Banner Duplicator Tracy Debugger Wire Mail SMTP Admin Links in FrontEnd Technical insights Most of the content is built using a Repeater Matrix field. Each section has an optional heading and a select-field for background colors. Some of the sections available include: Text blocks (a repeater-field for multi-column text) Feeds / listing of the latest job offers or news (with a field to control the number of entries shown) Displaying a team member or quote (selected through a page reference field) Downloadable files (a multivalue field for file uploads) Those sections can be combined and stringed together arbitrarily, so any number of page templates showing different contents can be built. The job offers template, in contrast, features fixed fields for taxonomy assignment, description, contact person, preview image and so on, making the job offer pages uniform and easily accesible. The (technically) most interesting part of the site is the job overview page, which contains custom filters that are automatically generated from the available taxonomy terms. The stylesheets are written in SASS, built with Bootstrap 4. Only the base and grid SASS files of Bootstrap are included, along with the Bootstrap components that we ended up using. Using Bootstrap 4 as a framework in this way makes development & styling blazingly fast, once all the utility classes are commited to muscle memory ... > Our Agency. Screenshots

I don't disagree with you, but I also don't want to pollute the dump output with lots of extra stuff. It could easily look quite messy with several object dumps, all of which have text / button links to the debugInfo and Full Object versions.

It's not really that simple though - a page object doesn't have count. In the case of count(), it is relevant to PageArray, PageFiles, PageImages objects, but also to field types with multiple values. Then there are template, field, module etc objects - what should be displayed for those?

I tried both. Here is left which is fine and does prevent the scrollbar jumping, I didn't like the way it affected left alignment compared to other dumps like the "test" one above, but maybe it's ok? I see where you're headed, and I like the idea but I am a little worried about going down a huge rabbit hole. Maybe if you can put together a list of PW objects and the data you think should be automatically displayed in this way, maybe we can come up with a solution. I am actually thinking that this might need to be another element that sits between the title (if defined) and the object dump. That's the plan - I haven't coded it yet so not sure - there could be some complications, but hopefully solvable.

Here's a screencast of the icon based switching in action. Is everyone happy with this approach? Any ideas for improvements? Back to @szabesz's idea of the page ID being shown - I have removed that from the recent screenshots/casts, but here it is again with the new icon toggles in place. What does everyone think about these automatic titles - useful, or unnecessary - I am not sure.

Playing with this idea where the toggles are icons floated to the right of dumps that have both debugInfo and regular object versions. Notice that the currently selected version of the dump results in the highlighted icon color. I think I need some help figuring out the most useful / cleanest looking option for this. Any ideas?

Ok, here is a really quick and dirty demo. Obviously the links need to look nicer and the selected one needs to be highlighted, but hopefully you get the idea. Any thoughts before I clean it up?

Morning ? Thanks for the thoughtful discussion @szabesz and @bernhard - I think I like Bernhard's idea of a toggle, although I think it belongs below the title, just before the dumped objects. I think I'll go with debugInfo and Full Object as the labels for the toggle though - I'd rather this was more explicit and helps to educate new developers about what they are actually seeing. I tried blending the debugInfo version into the main object and it works but it gets added to the data property, so you have to dig down to find it and it gives an incorrect impression of how the object is actually constructed. This would certainly be the simplest approach, but I'll take a look at implementing the toggle idea - I think if that works it will be the cleanest and most useful.

Eh, I added autocommit=0 to my cnf override, but it turns out PW is unable to create any pages (failed when I tried to create the parent page). Btw. another perf data point with an InnoDB install: Trash with 7232 pages emptied in 6 min 35 s. I don't think any of this is related to the CSV import module used.

Hmm, I guess InnoDB may be auto-committing on every insert. Try turning autocommit off for bulk imports - but it might not be a panacea. Reference and another. BTW, that's an interesting article - thanks for the link.

@thetuningspoon, it would be helpful if you could provide a limited test case (i.e. a minimal setup where this performance problem occurs), or if that's not possible/feasible, a description of the structure and this particular feature in as much detail as possible. For an example: What's the page structure like, and which part of it is cloned? Are users actual users or do you have "user" pages in a custom page structure – and if, do each of these have multiple orders? Or are you linking users to orders via a Page field or something along those lines? How many fields do your orders (if order pages is what you are cloning) have? How many Repeater fields there are, and approximately how many Repeater items (real content or ready items) do they contain? How many users/orders are you dealing with? Where in your page structure are you storing cloned orders? Are there any third party modules (or modules/hooks you've created) that could affect this? As you can see, this raises quite a few questions, and that's just the tip of the iceberg I'm afraid. All in all this sounds like something that would be easiest to debug by setting up a test case – otherwise it's difficult to isolate the issue. As @LostKobrakai already pointed out, 20 seconds for cloning a relatively small page structure is not normal, unless there's a massive amount of data to copy (in db or on disk). If you're dealing with a large number of items, Repeaters could of course also play a role in this: after all each repeater item is a Page, and their storage method can also result in bottlenecks at large enough scale ?

Try to increase memory_limit and/or upgrade to PHP 7.2. Are there a lot of files/images inside those pages/repeaters? Perhaps try a clone() action in Tracy Debugger, maybe you'll see some hints what's slowing it down.

30 pages * x fields is a whole lot of insert statements to do on every change to an order, but 20 secs sounds indeed like somethings off. That's nearly a second per page to clone. Is that the time it takes locally or in production though?

That was my suggestion: But I guess that's more effort than just implementing a new method dumpVerbose() with different settings. Let's wait for adrian to wake up - good morning btw ??

@gmclelland that real-estate site is most definitely built with PW, it has the x-powered-by: ProcessWire CMS header ? @OLSA just released a wonderful module a few days ago - with the main purpose of exactly that: storing various "setup" / configuration settings in just one single field, therefore avoiding native-PW-field-bloat. I tried it out and can really recommend it.

This might help https://css-tricks.com/screen-recording-utilities-for-macos/

What do you guys think about this approach. As you can see I have automatically combined the debugInfo and the full object versions into an array. I have also added an automatic title if one isn't specified. I was thinking about making this all work for PW's $page, $template, $field, etc objects. The one concern I have is that at first glance this looks like $page returns an array, so I wonder if it might be better simple, like this where the first dump is debugInfo, and the second one is the full page object, but they both are obviously a PW $page object. Not sure - what do you guys think? I am pretty keen to have both version output automatically, but I want it to be obvious what's what.

Yep, not much activity in this forum so as a new Padloper user, thought I'd share my feedback on this module here, originally posted in the Padloper forum:

Busy morning ? Firstly, a huge thank you to Steve (@netcarver) for his epic rework of the Diagnostics panel - take a look at the diff https://github.com/adrianbj/TracyDebugger/pull/24/commits/8604a683ef408b4106f7b7237b3eae6c24de315a - he's put in a huge amount of time on this. I have merged his changes and bumped up Tracy's version to 4.11.0 - it deserves a major point bump for this ? If you haven't used this panel much in the past, you really should take another look and give it a thorough go - it's really useful for new and experienced devs alike! I also also added @tpr's blue for the icon color. Not sure about the inverted scheme just yet - any strong thoughts on it? I do think that the background color of the bar (the light version) could be made to look a little less dirty though. BTW, as a reference, take a look at the default Tracy bar: https://nette.github.io/tracy/tracy-debug-bar.html - be sure to check out the panels as well - we have @tpr to thank for our version looking considerably better than that ? Regarding the automatic dumping of both full object and debugInfo versions, it could be as simple as this - just one version, and then the other. Perhaps some visual indicator so you know it's from one call or something. Any ideas/thoughts? @szabesz - you mentioned wanting the page ID shown without having to open the object - I don't think is any simple approach to do that, especially given that not all dumped objects are pages. Of course you can do: d($page, $page->id) but that's only useful if you are dumping multiple pages at once so you know which one is which. If you have any more specific thoughts on how to implement what you are looking, let me know. Regarding the memory limit error - not sure what can be can about that - I guess Tracy can't handle that error because the error broke Tracy ? Seriously though there is just so much output when you have all panels toggled on that it's not surprising that these come up occasionally - I haven't seen one, but I up the PHP memory limit on my dev machine to 128M. Hopefully I answered everyone's questions, and please don't forget to test the new Diagnostics panel and give @netcarver your feedback.

...please could you add a comment to the issue confirming that you are also seeing it, and add any additional information that may help. There are several issues that have the report and then some thumbs-up votes on them. This, however, is somewhat ambiguous, as I don't know if the thumbs-up is really saying "This effects me too" or just a "Well done for reporting this" or something else entirely. In order for me to unambiguously tag an issue as impacting multiple users, I either need to reproduce it myself - or I need people to clearly state that they are impacted by it. Whilst I can understand the use of thumbs-up emojis on the processwire-requests repo as a form of up-vote, I don't really think it works for the issues repository. If you have any other suggestions that may work unambiguously in this case, please let me know. Thank you for your consideration. Steve

It all depends. For some sort of projects, where you really need to have structured data (e.g. Skyscraper profile, or real-estate listing / database-like sites), a visual builder would do nothing for you, or your clients. otoh, for stuff like huge immersive storytelling sites, it's certainly a dream come true. (you know, stuff like this)

Congrats, that's a really fine site. I'm amazed how fast it is, even without ProCache or AIOM. But hey, it's ProcessWire ?

The role of my page.php page is to do this: Get the themes page and set it as a variable for later use. (Anything can access this page to get the asset timestamp, active theme, etc.) Set a variable for the selected page layout of the current page, so I know what uikit elements we are adding from that. If there is not one on the current page, check the parent for a detail page layout. Get a list of code snippets that target html tags for this page, sorted by priority. (If they match the page layout, the page, or are sitewide, implement them by adding them to the snippet array.) By implement, if its a code snippet type, it outputs the html or php using output buffer and adds to the snippet array. If its not a code snippet, it is a uikit item and I will start the output buffer also and include the template file directly. (I also set a variable for that page to use inside the template before I include it. (The $page variable gets saved as the template name.) So if its a section template, I save the $page data as a $section variable. In my "section" template, I can access itself with $section, or the root page it is on with $page. Inside the section template I can loop through $section children also, setting the children as $cell so the cell.php page can access itself with $cell->x After the snippet array is built using code snippets and uikit page templates, I loop through the /html/ page and its children. I pass that page to a render function, and it loops through the html tags listed and puts the snippets where they belong, outputting the result to the page. This is a delayed outputting format that lets a snippet tweak other snippets if needed, since they are stored in an array before output, and any snippet can target various parts of the page. ie. The last snippet loaded can still add to the head section.

Any time I have css, there are 3 main places I can put it. There is a "Themes" template that acts as a parent to all themes, and I have the Theme templates under that. The third is the page itself, which is usually a code snippet or a page layout or page. The Themes page controls the selected/active theme and holds styles that apply to every theme in its CSS box. The children are styles that only apply to themselves. So you could do a red theme, blue theme, etc. So in that case the navbar css that is not related to color goes to the parent, and all color related css would go to the child. That way you can change the active child and swap colors, but the child is nothing but color data so it is very easy to edit. They all get merged into one file on page save. The third is all page layouts, pages and snippets have css boxes as well, so if you want to add css to just one row, or one page, or one feature, you can do that without adding clutter/bloat to your theme. So if you add a sitewide snippet of "Thin Top Bar", you can add top bar css to itself so it is portable between websites. You move that one page and no theme changes are necessary on the new website. In fact, every code snippet has the fields for images, files, css, js, php, and html, so the whole feature should be portable between websites without touching the theme unless you want to. The module has 2 hooks. One hooks before page save to update the current page css and the other hooks after page save and merges all pages that have css boxes.

The current PW homepage has a few screenshots of the admin featuring the old UI. @ryan For what it's worth and because I had 5 minutes I remade it in the new UIKit theme. It's just a screengrab - nothing fancy. Might not even be the right size but it's been annoying me irrationally for months ?

Unfortunately it depends on the load order of the modules. If Tracy is loaded before the module you are trying to debug, then yes it will work. I use it regularly for debugging when developing modules. Unfortunately, the order that modules are loaded seems to be pretty random (although I haven't looked into this properly). I have put in a request to Ryan to add a way for Tracy to be loaded earlier, but I haven't heard anything on that. I'll keep it mind to see if there is a solution I can come up with to get it loaded earlier though - it might be possible to include the required files manually in the root index.php or something like that, but it could get messy.