Leaderboard

Well, you could say that PW has a gap when it comes to front-end anything. I don't know if there's a good authoritative document explaining this anywhere, but I think it's fair to say that part of the PW philosophy is that the core does not get involved with the front-end of your site. Depending on how experienced you are with front-end development this is either something that makes your job easier or more difficult. So you have all the freedom (likewise, responsibility) to do whatever you want with your front-end and PW will never mess it all up for you (likewise, help build your front-end for you).

http://blog.zend.com/2017/01/10/the-state-of-php-in-2017/ Yes definitely go for 7.x

Hi guys, here is our most recent website http://patina-store.de/ Patina is a really nice vintage objects and furniture store here in Wuppertal. Pay a visit if you pass by We are aware of some flickering and strange scrolling (seems to happen with Safari on desktop and iOS) on the homepage initial transition. I'm looking into it, but if you guys could report how it's behaving with you, it would be a great help! A point of interest is the Lookbook page. For this we used the Image Marker module by @kongondo and @heldercervantes, which worked flawlessly. Thanks guys! Although the site is very simple, PW has a very important role, since we transitioned all the shop organization (mainly the products) from excel spreadsheets to it. We could say PW is acting as a small CRM, and Lister Pro is doing a great job at it.

Hey @bernhard - I just quickly hacked together a new $pages->findArray() method that you can use like this: $pages->findArray("parent=12593", array('title', 'integer'), 'object'); It takes 3 arguments: selector array of fields to return return an array or object It needs to be cleaned up (eg properly bind values etc), but as you can see in the screenshot below that it returns an array of the requested fields for 5000 pages in 66ms. I wonder whether there is justification for something like this in the core? It seems like a pretty efficient way to get just the fields you're interested in without the overhead of page objects. You can obviously then do: Object foreach($pages->findArray("parent=12593", array('title', 'integer'), 'object') as $p) { d($p->title.':'.$p->integer); } OR Array foreach($pages->findArray("parent=12593", array('title', 'integer'), 'array') as $p) { d($p['title'].':'.$p['integer']); } This certainly isn't specific to your module - I am definitely going to be making use of this in the future for my sites when I need data for tables / charts, etc. Here is the hook code: BTW - the "title" field in the results below is correct to be a number - these were 5000 API generated pages with numeric titles.

@titanium Sorry for the extremely delayed answer. Thanks for pointing on this. I pushed an update which allows to use InputfieldColor as a config field for modules. I have made some changes in the code you have posted and tested it within the following module. Everything seems to work. Please check out. <?php namespace ProcessWire; class My2Module extends WireData implements Module, ConfigurableModule { /** * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'My2Module', 'summary' => 'Module with Config Input of type Color', 'version' => 100 ); } static public function getDefaultConfig() { return array( 'color' => '#ff3300' ); } public function __construct() { foreach(self::getDefaultConfig() as $key => $value) { $this->$key = $value; } } /** * Initialize, attach hooks * */ public function init() { // ... } /** * module settings * */ static public function getModuleConfigInputfields(array $data) { $fields = new InputfieldWrapper(); $defaults = self::getDefaultConfig(); $data = array_merge($defaults, $data); $colors = [ 'name' => 'color', 'inputType' => 3, 'type' => 'color', // will search for 'InputfieldColor' // 'outputFormat' => 3, // REMOVED outputFormat is related to the Fieldtype and not to the Inputfield // 'defaultValue' => '#ff0080ff', // REMOVED @see getDefaultConfig() and __construct() // 'alpha' => 0, // REMOVED related to 'inputType=4', otherwise automatically set by the Inputfield 'spectrum' => "showInput: true\nallowEmpty:true\nshowAlpha: true\nshowInitial: true\nchooseText: \"Alright\"\ncancelText: \"No way\"\npreferredFormat: \"hex3\"", // 'class' => 'FieldtypeColor', // REMOVED (unnecessary) 'label' => __('Label'), 'description' => __('Description'), 'required' => false, 'value' => $data['color'], 'notes' => __('Initial value: '.$defaults['color']), ]; $fields->add($colors); return $fields; } }

PHP 5.6 (and even 7.0) no longer receive active support (both versions receive only security support). You should use PHP 7.1 (matured) or 7.2 (recently released). I tend to wait a little while after major releases (anything can happen), so I’m currently sticking with 7.1 – probably until around March next year (birthday time, hehe). Refer: https://secure.php.net/supported-versions.php

thx, this was only for testing thx, didn't know that! writing on an answer in the datatables thread - i'm working on your findArray hook

Personally I have just alway felt more comfortable with JOINS so I totally understand where the OP in that SO thread is coming from Don't forget about: $rows = $result->fetchAll(PDO::FETCH_ASSOC); That will save the time required to loop through all 10,000 results to populate an array Also, you should probably be using $database (PDO), rather than $db (mysqli)

I've been working with different CMS's for quite a few years now but there was always one thing that bugged me, I never knew how the CMS takes a url and resolves a page ID from it. I knew it was to do with the "slug" but what i couldn't figure out is when it came to sub pages, as the slug only refers to the page itself not the parent pages in the url e.g /parent-page/sub-page. The main two CMS's i've worked with are Wordpress and ProcessWire, ProcessWire always has the upper hand when it comes to speed, even a large PW site is tens of milliseconds faster than a fresh Wordpress install. With the resolution of urls to pages being (probably) the most used query in a CMS i thought i'd investigate the two different approaches. Both ProcessWire and Wordpress split the urls by forward slash to extract the slugs /about/people/ => ['about', 'people'], however ProcessWire takes a completely different approach when it comes to resolving a page ID from these slugs. ProcessWire uses this query: SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN pages AS parent2 ON (pages.parent_id=parent2.id AND (parent2.name='about')) JOIN pages AS rootparent ON (parent2.parent_id=rootparent.id AND rootparent.id=1) WHERE pages.name='people' AND (pages.status<9999999) GROUP BY pages.id LIMIT 0,1; Resulting in a single item of the page in question including the page's template id. For urls with more parts it looks as though ProcessWire creates more JOINS to essentially walk back up the hierarchy and fully resolve the ID of the correct page. Wordpress on the other hand takes a different approach: SELECT ID, post_name, post_parent, post_type FROM wp_posts WHERE post_name IN ('about','people') AND post_type IN ('page','attachment'); More elegant looking however it returns a list of potential items. So requires a loop within PHP to walk the hierarchy tree and determine the correct page ID. Both queries once cached by MySQL took 19-21ms to return, ProcessWire looks as though it uses this to it's advantage by returning the correct page ID straight from the MySQL cache and doesn't require the extra looping step afterwards. Interesting to see the different approaches to the same problems.

Sort of tucked in here... http://processwire.com/about/what/ ..."tools to get at your data, but you make the markup"

The same way Lister does - with an ASM field that lets them select fields and sort the order they will be displayed in.

We're loading only the @ from Hind Madurai, notice the import line: @import url("https://fonts.googleapis.com/css?family=Hind+Madurai&text=@"); I know we're being picky, but we really really dislike the @ from Woodford Bourne. Anyway, thanks for digging in and telling me what you found. I appreciate it.

File Editor GitHub https://github.com/f-b-g-m/ProcessFileEdit matjazp version https://github.com/matjazpotocnik/ProcessFileEdit A module that allows you to edit file directly in the in the admin area. First module and first time doing a file editor so the way i do it might not be the best. Feedback is welcome. Editor page Setting page

When you can find a setting in admin and you want to know what the property name will be in API, a handy trick is to hover the collapse toggle of the setting. When $config->debug = true you will see the name of the input appear, and 99% (all?) of the time that will be the property name in the API. And Tracy will give you the whole shebang:

@Robin S thanks, well I've been two days exploring all possible scenarios, then a simple $type = $inputfield->inputfield; made my day aka that's exactly what I was looking for! many thanks

I have been using PW for a few days and I can say that it is a powerful tool for creating web sites, web applications, services, etc. However, doing research on the web, it seems to me that PW has a gap especially with regard to front-end forms development. I refer to the possibility of quickly and easily implementing forms to be used in the front-end to allow users to create new pages. In particular, I would like to allow registered/authenticated users to submit forms on the front-end as I (superuser) can make in the back-end of PW, comprising the bundle of input fields features such as for Multiplier, Repeater and Page. Although I tried to address this gap buying the FormBuilder module and later ProFields, the implementation of front-end forms seems to be still a "hard job" because, if I understand correctly, and since I cannot use almost all of the ProFields fields with FormBuilder, I have to write API-based code to get some sort of "legacy solution" e.g. see Front-end tips, tools and general development. From a developer's point of view, front-end forms development and implementation in PW should instead be as easy and linear as using the FormBuilder module, designed specifically to work for the PW front-end. Said that, and with respect to everything of powerful that has already been done, my question is: why does front-end forms development not seem to be reasonably addressed at the core of PW?

updated the hook in my previous post to support queries of the pages table itself (like templates_id, created_users_id and so on). edit: this solution is not the best, imho. It would be better to have one array with all fields and then split this array automatically (like this: if field part of pages table query this field directly else join field_xxx )

The only limit is what is hit by the "max_allowed_packet" setting. As for the performance, I think we're probably OK because "id" is indexed. If it wasn't, we'd be in trouble. Might need to do an extreme test to really know. I suppose an SQL query completely from scratch would be more efficient, but using findIDs certainly simplifies lots of things as you noted, and especially if the selector gets complex - groups, subfield values etc.

hi adrian This is a GREAT idea Very helpful indeed! I think that should definitely go into the core. I see you are using joins for your example. As mentioned here I think it's better to use subqueries in our case because it makes the query easier (to read, write and construct) and it makes it easier to query other fieldtypes (like repeaters or the like). here is my modified version of your hook. I think that could really be helpful in many situations. I would suggest using $pages->findArray() and $pages->findObject() as different methods. Easier to remember and more self-explaining $this->addHook("Pages::findObject", function($event) { $event->return = $this->pages->findArray($event->arguments(0), $event->arguments(1), $event->arguments(2), true); }); $this->addHook("Pages::findArray", function($event) { $selector = $event->arguments(0); $fields = $event->arguments(1); $fields_pages = $event->arguments(2) ?: []; $type = $event->arguments(3) ? \PDO::FETCH_OBJ : \PDO::FETCH_ASSOC; // todo: check for empty pages find operation and early exit // $this->pages->findIDs($selector) // https://processwire.com/talk/topic/18558-mysql-database-to-processwire-pages-opinions/?do=findComment&comment=162328 // build sql string $sql = "SELECT\n p."; // add fields of pages table $fields_pages[] = 'id'; // make sure we return the page id $fields_pages = array_unique($fields_pages); $sql .= implode(",\n p.", $fields_pages); foreach($fields as $f) { $field = $this->fields->get($f); if(!$field) continue; $fieldtype = $field->type; // fielddata is always stored in the "data" column of the field's table // multilang fields have several data columns identified by the language id // we use a variable to query the current user's language, eg data1234 $data = "data"; switch(true) { // if it is a multilang field we append the language id to query the correct column case $fieldtype instanceof FieldtypeTextLanguage: case $fieldtype instanceof FieldtypeTextareaLanguage: if($this->user->language->name != 'default') $data .= $this->user->language->id; // no break here intended! // build sql query case $fieldtype instanceof FieldtypeText: $sql .= ",\n (SELECT $data FROM field_$f WHERE pages_id = p.id) AS $f"; break; case $fieldtype instanceof FieldtypePage: $sql .= ",\n (SELECT GROUP_CONCAT($data SEPARATOR ',') FROM field_$f WHERE pages_id = p.id) AS $f"; break; default: $sql .= ",\n '$fieldtype not supported' AS $f"; } } $sql .= "\nFROM\n pages AS p"; $sql .= "\nWHERE\n p.id IN (" . implode(",", $this->pages->findIDs($selector)) . ")"; $results = $this->database->query($sql); $event->return = $results->fetchAll($type); }); This is really easy to extend for all other fieldtypes (and maybe we could also implement a feature to add a custom query as returned field?). I also added support for multilanguage fields (see field1 in the example): btw: querying the database via a pages->findIDs query is a very good idea because it already takes care of page status and access control does anybody know any limitations for the length of the query (querying 10.000 pages means having 10.000 ids in the sql statement!). edit: I'm querying 10.000 pages again in the example and this was the resulting query: SELECT p.id, (SELECT data FROM field_title WHERE pages_id = p.id) AS title, (SELECT data11041 FROM field_field1 WHERE pages_id = p.id) AS field1, (SELECT GROUP_CONCAT(data SEPARATOR ',') FROM field_test_page WHERE pages_id = p.id) AS test_page, 'FieldtypeRepeater not supported' AS test_repeater FROM pages AS p WHERE p.id IN (1016,1017,1018,1019,1020,1021...) PS: The "FieldtypeRepeater not supported" part is just for demonstration. I think a repeater should return ids just like the "test_page" field in my example does. Maybe we should use a pipe as separator so that you can instantly use the returned value as a $pages->find() selector?

I'm sure you'll love it I'm glad you chose my blogpost as a tutorial but keep in mind that this was intended to show how to build process modules. I guess there are better resources for regular modules out there edit: just saw you already mentioned it: yes, you don't need a process module for that. i created the tutorial because there are lots of tutorials and examples of how to create regular modules but only very few that cover process modules. creating your own fields (fieldtype/inputfield modules) is a little more complex. i would recommend you start by creating a simple module that loads some javascript, hooks into something (like modifying markup of other fields) this is a simple example of one of my first modules that covers lots of basic principles and that you can use for learning: https://github.com/BernhardBaumrock/TemplatePreviewImages (note that $config->scripts->add() only works when the fields are not ajax loaded)

Processwire is a decoupled system. The front end is totally up to you, that's why processwire is loved by so many people. But about forms, if you go through this thread a couple of times, you will be making forms real quick: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/

I haven't used Atom personally, but looking at the documentation, the PHP plugin looks like an early release and it doesn't mention debugging, but VSCode seems to support full debugging. Someone who's used Atom may be able to comment regarding debugging.

Great - thanks for testing. It all seemed right here too, but it's nice to have another pair of eyes on it.

@adrian: I tested 2.0.5, everything worked as expected. Another improvement, thanks! Just for the records, I only tested importing TSV by clipboard, not to import a CSV file. All possible variants: TSV with two columns, four columns (no empty cells and rows with two empty columns), TSV with five columns--into the mentioned field with four columns.

@adrian I'll explain more details tomorrow just a quick question: if you only define data by a selector, how would you define which columns to show (which fields, which columns headers)? But you brought up yet another idea in my head

Hey @bernhard - glad you're going to offer both. On the use of findIDs() - I don't think I explained properly. My ideas was to take the returned IDs and build up a manual SQL query using those. Here is what it might look like this. It's rough, but it's running on 5000 pages and this returns the id and the title in 47ms and all that is needed is a simple selector - in this case: parent_id=xxxx Does this suit your needs?

No less than issue #1. I added another comment, maybe will catch Ryans' attention.

Ouch, this could be a problem. I haven't looked at the built in PW comments and they might work. However, I still need to make a module!

I'm not aware of any additional work on this. Please give it a thumbs up at my GitHub request and you might also want to express why. New features are often added to ProcessWire when it is asked by lots of us...

We are getting very close to our next master version of ProcessWire 3.x. This week work continued on covering issue reports, but we also added a few items from our feature requests repository as well. This post contains a brief summary of what went into the core this week. https://processwire.com/blog/posts/pw-3.0.86/

Module refresh will show any changes you make to the info without having to re-install it.

When you navigate away from the page that uses your process, any changes should be reflected the next time you visit that page, unless you are modifying the module config fields. I have phpstorm open with my process module, and the module installed on localhost. When I make a change to the code, I simply select another menu option, such as pages, then re-select my process module menu and the changes are immediate.

I didn't integrate Disqus so far in any PW site (or anywhere else, for that matter), but I guess this very fine tutorial should get you going: https://abdus.co/blog/creating-a-simple-and-configurable-module-for-processwire/ Especially the "Building a configuration page" chapter.

A better solution IMO: before changing pathes, install PagePathHistory. This one does it automagically for you, without the need of an (optionally error prone) extra step. It is a core module that only needs to be installed: You will find it in the admin under: modules -> core-tab (-> section Page) PS: the great Jump-Links module from Mike is the tool when it comes to handle links from earlier sites / cmses and such stuff. But once you runs a PW site for the first time, you should enable PagePathHistory, IMO. Only exception are sites that programatically create, modify and delete a high amount of pages / urls. But for all others, I enable this by default.

Should also add... if you decide to change the abcd page URL, you should also consider redirecting any backlinks pointing to the old URL to the new one. Module comes to mind but have no idea if it works with PW 2.3

Don't be put off by what your competitors are doing. They can be wrong. Google gives lower ratings to pages that it sees as lower down the page tree... eg page abcd in the tree abcd.com.au/all/about/abcd would rate lower (probably 40%) than page all-about-abcd in url abcd.com.au/all-about-abcd (probably 80% as it's one page off the root) Google is also smart enough to recognise hyphens in URLs as spaces. The only suggestion I would make would be to rename the URL to abcd-is-about - that way abcd is up front Hope this helps

You got me thinking. I do work as a single developer, but increasingly I'm finding I want to deploy solutions I've developed for one project to another, and just copying and pasting via the admin isn't ideal. I was having a look at Silverstripe recently, as I have a possible project where Processwire, though I'm sure can do the job, might meet some resistance, whereas Silverstripe will almost certainly be accepted as it's mandated as the CMS of choice by government here (NZ). What struck me is that you can do far more with Processwire with less coding, but in some cases defining data structures via coding rather than via an admin UI may be more appropriate for sharing code between projects or in the case of a team between team members. Processwire is perfectly capable of doing this as the admin UI is just a layer on top of the API, so there's no reason why fields and templates can't be defined programmatically in modules that are subject to version control. I notice that some of the existing modules actually consist of several dependant sub-modules, bundled in a common folder, so it would be easy to set up something like this with git version control. Silverstripe automatically rebuilds database schema by using a /build URL, however it doesn't remove unneeded fields or tables after a schema change, whereas the Processwire API makes it fairly easy to both add and remove fields via a module. Processwire will detect changes to a module version, and run any update process automatically, so even though it bypasses the ease of use of the admin UI, developing your database schema programmatically in modules might ease collaborative development.

I do it differently, I use the google recaptcha module here - can install it via classname (MarkupGoogleRecaptcha) in the admin (modules page). So, in my form at the top (where you include valitron): $captcha = $modules->get("MarkupGoogleRecaptcha"); ...then to render it, just: <label for="recaptcha">Recaptcha (required)</label> <!-- Google Recaptcha code START --> <?php echo $captcha->render(); ?> <!-- Google Recaptcha code END --> ...and to check the response: if ($captcha->verifyResponse() === true) I found this way easier. You fill out the secret key and stuff in the module instead of pasting it into your php file.

did a total rewrite of the module and will release it the next weeks when i'm done

alan, you can use markdown or textile syntax in description fields. http://en.wikipedia.org/wiki/Markdown This was mentioned here: http://processwire.c...__fromsearch__1 Markdown is a module in PW by default (textformatter), textile version is also existent. you can, using markdown, simply do this to make links in field description : [linktext](someurl) *** corrected some