Leaderboard

We've been expieriencing high load for some reason for the past 12+ hours though not sure where it's coming from as yet. As a result the site has been slow/showing error messages. The site and forums are up for now but please bear with us whilst we investigate.

decimal fieldtype would be GREAT

Inputfield Selector Select ID Uses the Page List Select inputfield for user-friendly input of page IDs into Inputfield Selector. Overview This module adds a feature to Inputfield Selector, which is most commonly seen in Lister (Find) and Lister Pro. When adding a filter row for "Parent", "Has parent/ancestor" or "ID" the user is expected to enter a page ID to match against. But this is not as user-friendly as it could be because the user may be able to identify the desired page by its title or location in the tree but not know its ID. This is particularly the case for site editors who may not even understand the concept of a page ID. So this module adds a thunderbolt icon to relevant rows in Inputfield Selector. When the icon is clicked a Page List Select inputfield opens in a modal window, allowing the user to visually select a page from the tree. When the modal is closed with "OK" the ID of the selected page is inserted into the filter row. Tip After a page selection has been made in the modal window the "OK" button will automatically receive focus so if you prefer you can close the modal by hitting the Enter key rather than mousing to the OK button. Installation Install the Inputfield Selector Select ID module. https://github.com/Toutouwai/InputfieldSelectorSelectID https://modules.processwire.com/modules/inputfield-selector-select-id/

Thanks for working on FieldsTableTools, supporting uniqueness at the DB level is an important addition to the system for sure! However, while you are at it, please also consider this HIGHLY POPULAR request: https://github.com/processwire/processwire-requests/issues/126 Looks like this is the right moment for you to also implement a decimal fieldtype for the core.

You need to create a database and a user for the database before you complete that part of the PW installation process. Then you will know the database name, user name, and password for the user. I'm not a XAMPP user but I'm pretty sure that it comes bundled with phpMyAdmin. So you open phpMyAdmin in your browser (probably at http://localhost/phpmyadmin) and then the quickest way is to create the user and database in one step at User accounts > Add user account After you have created the user/database then you will know the user name, database name (which will be the same as the user name) and the password so you can complete the PW installation process.

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

... and everything went silky-smooth. I finally got around to update a small portfolio site from PW 2.3 straight to latest dev. I spent roughly one hour, tested everything, and hey: no major hassles. I updated the few modules I used (and installed some new ones like Tracy or AoS), updated PHP as well, and that was more or less it. Imagine having such an un-touched WP, Typo3 or MODX site, and updating straight to the latest version... What a nightmare. That is - if they would actually still run that long ? I actually expected it to go as smooth as it did, but I'm always surprised and in awe again when I do such a big update. Thank you ProcessWire.

Did the same some time ago, as PW 3 was released. Replaced the wire folder, and that was it.

Heya! Just released Wireframe 0.9.0. Here's the changelog for this version: ### Added - New EventListenerTrait. Currently used by Components only. Adds support for listening to and emitting events. - Support for Renderer modules for adding templating engine support for view files, component view files, etc. - New Page methods Page::viewTemplate(), Page::getViewTemplate(), and Page::setViewTemplate(). - New method Component::getData() for manually defining the data passed to the component view. ### Changed - Controller::init() and Controller::ready() are now hookable methods. - Component::setView() and Component::getView() are now final methods, preventing accidental overrides. - Layout file is no longer necessary; if it's missing, the page can be rendered using just a view file. The component system is a bit more mature now, and there are a couple of new features: Component::on('event-name', callable $callback) can be used to listen to events emitted by a Component instance, and in a Component class events can be emitted with $this->emit('event-name', array $args). This is mostly just syntactic sugar on top of the hook system, but it seemed fun and potentially useful, so... ? The Component base class extends WireData, so by default what gets sent to the component view when a component is rendered is the internal $data array. Since 0.9.0 it's possible to alter this behaviour by implementing getData() method which returns the data that the component should expose to its view. Another "big" update is support for renderers. These are add-on modules that add support for different rendering / templating engines to Wireframe, and the first example is the Wireframe Renderer Twig module. I haven't really used a templating engine in a while so it's possible that I've missed something important, but in my limited tests the Twig engine seemed to work quite well right out of the box. I'll likely add a separate module for Latte at some point, just to make sure that the logic works for other engines as well ? By the way, it looks like I forgot to post here about Wireframe 0.8.0. It was released last month, and here's the related changelog entry: ### Added - Support for Components, along with a new static factory method Wireframe::component($component_name, $args). - Support for rendering pages that have not been "routed" to Wireframe using the altFilename template setting. - New static getter/factory/utility method Wireframe::page($source, $args). - New static utility method Wireframe::isInitialized(). ### Changed - Wireframe::$initialized is now a static property. This was a necessary change so that Wireframe::isInitialized() could be implemented effectively. On a related note I'm considering tagging the next release as 1.0.0. We've been using Wireframe on production sites for a while now, and I can't recall any truly breaking changes so far, so I think it's already quite stable ?

Thank you @Robin S $pages->uncacheAll(); did the trick.

Loaded pages are cached: https://github.com/processwire/processwire/blob/master/wire/core/PagesLoaderCache.php Try calling $pages->uncacheAll() between renders of the same page.

I think, what you might be looking for is the 'Family' settings for templates. Here you can define, what child templates are allowed for a parent page with a specific template. So, for example, your parent page 'Blog' for your blog items might have the template 'blog' and the child pages (your blog entries) have the template 'blog-item'. In the template's 'Family' settings for template 'blog' you can define to only allow template 'blog-item' as child template. And in the template 'blog-item' you can define to only allow template 'blog' as parent template. Now when an editor adds a page to 'Blog' in the page tree, the new page will automatically get template 'blog-item' assigned.

Well then... I guess I can delete my module haha Nice one, I'd heard of AOS but didn't think to check it for this feature. As I said, I was just playing with it for my own sake and thought that since it was a small change it might be able to be included. Didn't think to use hooks (and to be honest I'm not sure I would have known which ones to use and how to do it in this case). Thanks for the input, happy to learn!

... and, if you want to do something that AOS doesn't support, one should use HOOKS instead of rewriting core modules, to avoid the version update hassle. ? TLDR; Following some example code from 2014/2015, (written before AOS was released).

Isn't AdminOnSteroids pagelist tweaks suit your needs? https://github.com/rolandtoth/AdminOnSteroids/wiki/PageListTweaks Show pagelist actions on full row hover: makes pagelist actions visible on hovering anywhere in the pagelist, not only on the page title

I just submitted my first module to the PW modules directory. The module is a full featured e-commerce module but I couldn't find a corresponding category there. May I suggest that a responsible person add a new category "e-commerce" (or something similar)?

The easiest way to change the logo is by going to (once logged in) Modules -> Core -> AdminThemeUiKit . You will see a section labeled Masthead + navigation. You should then be able to upload a new logo for the backend through the field provided. As far as changing colors of the header, the easiest approach might be to follow what Jonathan Lahijani said here:

On the other hand, "flat", that is non-normalized tables, scale only somewhat. Where they don't scale well is in update performance, so if a site is highly dynamic, updates create massive locks and those locks impact the frontend too. Then, if a CMS uses non-normalized tables, multi-valued and complex field contents will have to be serialized and de-serialized to fit into their column. That's only fine until you want to search for it. In that case, things get ugly, and if that search can even be implemented, it will be a much worse performance hog than ten extra field tables in PW. The web server question "does it scale?" is usually not answered by database statistics. It's answered by a concise design that allows for good, hierarchical and atomic caching strategies. If a site is designed with that in mind (and even sometimes when it isn't), performance can easily be improved. I like to take our corporate intranet as an example, with 12000 active pages, now 125 templates, 28 repeaters, 35 site modules, 220 additional php scripts and everything a good book on website speed basics tells you not to do ? We have around 1000 users who use it daily, and a good number of them have a few auto refresh pages loading every 2 minutes. I'm running opcache, use processwire's $cache interface to populate recurring, user dependent patterns in some fields and have a small home-written module that uses memcache to store and refresh data that would otherwise be retrieved from external systems with each call. First time page load including fonts, styles and a healthy collection of scripts is about 5 seconds. Times to page view for consecutive visits to the site are almost always below 2.5 seconds. Everything runs on one single server, including the database, and there's no caching proxy in front of it. That's on PW 3.0.125. I'm currently in the process of upgrading to latest IIS, latest PW stable and latest PHP. My first impression is that I'll probably get the time-to-view reliably below 2 seconds with a bit of tuning.

I think the reasoning for the above is quite plain: The web becomes a deployment target. "Proper" HTML is not a business goal at all. Performance/Accessibility/Maintenance/… are. For twitter there's probably also in more detail: Is it easily maintainable with many devs/teams even with high developer fluctuation and potentially ones, which are not super knowledgable in the realms of "proper html"? Are components/design guidelines enforceable over all of their platforms? Can components be widely/easily reused? Removing as many bytes at compile time out of the markup because compile time stuff is cheap. Removing nested divs is dangerous at compile time. Using short unreadable classes on the other hand is simple if you have all markup/css at hand. Sure accessibility sometimes comes for free with semantic html, but I guess at the scale of twitter even bugs/inconsistencies between the accessibility implementations of browsers will surface and simply doing everything on your own might give you the ability to work around those issues. And twitter likely has the manpower to do so, which is probably not true for anyone here. We struggle with styling those damn html inputs, twitter has probably more obscure browser inconsistencies to care about. All those things make companies like twitter/google/facebook kinda like the worst examples to follow. The tradeoffs those companies do will hardly ever match with the tradeoffs smaller agencies/companies/single developers should/would choose. I see similarities to go and google. Go was created because google had problems with getting young, unexperienced, directly out of college developers up to speed. Therefore they created the a simple to grok C like language with a GC and easy concurrency. Their proper error handling is literally a truck load of if statements. It's nowhere near what more experienced people would expect from a programming language. But it does what it was created for very well and as it's stuff on the server nobody cares if it's particularly verbose or not very abstract. If you want "beautiful" server side applications rather look for a handful of senior erlang developers than a whole can of go developers.