adrian

haha - I thought you could do a diff on it somehow. Maybe before generating the html you could compare the php array?

I wonder why I am getting 830 on dev vs your 800? Can you figure out which ones are missing?

Right. Looking at the code in that script that is making use of wire - some of it could easily be stripped out for your use case (some of it is to check the existence of the ProcessWireAPI module for directing to API docs on the PW website vs local install) and some modified to not need wire at all (that check for DOTS in the path).

I guess the File Compiler is taking care of that for me. Any reason you can't just namespace once at the top? Anyway, I'll leave it to you if you want to make use of it.

Hi Soma, Just wondering if you would consider implementing the latest code from the Tracy Captain Hook parser. It us returning 830 core hooks compared to the 770 listed on this Captain Hook page. Also, you have this error showing at the bottom of the new version: Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Users/philippurlich/Documents/projekte/pw2.1/PWCaptainHookCLI/generate-html.php on line 82 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Users/philippurlich/Documents/projekte/pw2.1/PWCaptainHookCLI/generate-html.php on line 83

Rather than chartjs, can I suggest something that outputs SVG (not canvas) and is potentially based on D3js to make it easy to manipulate beyond the charting library's built-in options. SVG gives more options for exporting the charts for use in vector graphics editors. I admit I haven't done a chart heavy project in a couple of years so I am not fully up to date, but I quite like http://c3js.org/ - they are not the sexiest charts by default, but you can manipulate however you want via CSS and D3js making it incredibly flexible. There might be other good/better options out there now also so definitely worth some research time.

An extra +1 for using the the Console panel's code injection feature for testing hooks

Looks great. Nice little typo "They are fucused problem solvers"

I think it would be used quite often in a datatables type application, but I also am not sure about just how far to go in terms of getting away from SQL which is already very effective. I guess my main goal is to remove the need to understand the PW table/field structure/relationships, but you have put a lot more thought into this than I, so feel free to ignore my ramblings

In the page tree, go to Admin > Blog and EDIT and it should look like this:

But you know SQL - I am trying to think of the devs that don't and are used to the PW API. Remember you not only need to know SQL, but you also need a good understanding of the PW database tables structure with the names of the tables and that content is stored in the "data" field. To this end, I would suggest: 'myfield' => 'YEAR()' I'd love to see that converted to: SELECT YEAR(data) AS year FROM field_myfield WHERE pages_id = p.id AS myfield so take the name of the function and lowercase it and return it as "year" for the key/property in the array/object. I think this could be really useful.

Are you asking how I would do it without this module because of my question above about why this module's approach is better than calling the functions directly? I would have just written the code to parse those tags myself or I would simply the tags that are required by the editor. Maybe simply {fullname} and {invitelink} and do a simple: $subject = str_replace('{invitelink}, $invite->link, $subject); Or if it works better for you, then I think it's a great use case for this module

Could this be abstracted to something like this: 'YEAR(mydate)' => 'year' This would result in a "year" key in the returned array/object that returns the YEAR from the mydate field.

@bernhard - I haven't looked into the best way to incorporate it yet, but before I forget, I think it would be great to be able to add mysql functions to these new $pages methods. For example, it would be great to be able to directly get the YEAR from a datetime field using YEAR(datetime) AS year. Lots of other options of course, but that should give you an idea of what I am thinking.

Agreed - I am running 7.1 on live and 7.2 on dev

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.

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)

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

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.

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

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

If the selector is that simple, then sure SQL is easy to write. Maybe I am missing something, but my assumption is that currently the user will have to write an SQL query themselves to get the pages they want. Is that correct? If it is, then my thought was that using findIDs would let you take a selector (generated from InputfieldSelector) and then pass those IDs into an SQL that is generated by your module. That way the user wouldn't have to code anything - all GUI via the InputfieldSelector (what is used by Lister/ListerPro etc). Does that make sense, or am I still just confused about how this module works? PS - in my example above there is not actually any reason to even get the id from the pages table because you already have that (obviously). So you probably just need to get from the db tables for each of the fields that you need to present.

@Lutz Heckelmann - just realized that I should also exclude trying to insert any additional columns in case the users has copied more columns than the table has. Would you mind doing another check at your end to make sure everything still look ok? Thanks!

I completely agree - I do think it's going to be a very nice improvement for many users - thanks for the suggestions!

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?