BitPoet

Probably an update of MySQL to 5.6. Disable STRICT_TRANS_TABLE and the message should disappear.

The message just says the user or password is invalid, and that the client did provide a password. Invalid user may also mean that the configured user account is only valid for '%', which means any remote client, not localhost. You did create the fubar@localhost user, didn't you?

Does chown'ing the htdocs folder including the PW installation files to the webserver user and group (I think that used to be apache:apache in standard EC2 instances) before starting the installer help?

Check document.getElementFromPoint(point close to top) if it's in one of your tables and either check only that one's scrollTop or see if it is not inside the thead?

The interesting information is (or should be) in the Risposta tab on the right.

Green just tells you that the request itself completed, but not if the returned content is valid. You have to click on the last entry there (the request for /processwire/page/list/) and look at the returned content. You'll likely find some kind of error output in there that can give you a better clue at what's going wrong on the server side.

Remove the line where you call $prm->repeater_videos->add. getNew() already adds the item, you just need to fill and save it. Edit: the same should be true for $page->repeater_matrix_content->add

I just whipped up a little test on a freshly installed PW, and there it definitely works without being logged in, so it has to be something else. Is the module/include adding the hook loaded for non-superusers?

The easiest approach would be to add a hook in your module after getViewActions that modifies the event's return value and replaces the URL for every returned array element.

If funny things are going on when saving pages, it's also always worth looking if Apache's mod_security is active. If the answer is yes, I'd starting digging there (and disable it to test if it is the culprit). It wouldn't be the first time that changes between 2.7 and 2.8 trigger some filter mechanism there. I don't think there's anything wrong with the database if you don't see an error message.

This footer looks like it contains lists of links. My first thought would be to create a repeater field "footeritems" consisting of a text field "label" and a page field "links" configured to hold multiple pages. Then you add a repeater item, give it the label "Category" and add all the pages like "Tanks & Spaghettis", "T Shirts & Polo T Shirts", ... Your PHP template then only needs to loop over the repeater, output the label as the heading and the pages as list items. Of course, this assumes that all the links shown exist as actual pages and not just URL segments. foreach($page->footeritems as $item) { echo "<div class='uk-panel'><div class='uk-panel-title'>{$item->label}</div><ul>"; foreach($item->links as $link) { echo "<li><a href='{$link->url}'>{$link->title}</a></li>"; } echo "</ul></div>"; }

Just a thought, since this is what I try to do with my own modules: could you add hookable methods in ProcessGraphQL that allow implementing custom restrictions? These hookables could be no-ops if not hooked and receive all information about the query at the time of calling, enabling users to filter or reject queries before or after they've run. It's an intriguing module in any case. Thanks for sharing it with us!

Not sure if there's a solution yet, but there's an open issue in PW's github request page already. Upvoting that may heighten the chance to see it implemented.

Just like $pages->get, $users->get returns a NullPage object if no match was found. Thus, you can check for that. I feel that doing it this way is better for readability (implicitly illustrating the difference between a new User object with no id and the result of a get call with no match), but that may just be a personal preference. $item = $users->get("email=example@processwire.com"); if($item instanceof NullPage) { // Not found } else { // Do something }

Pages::published perhaps even more so

Have a look at wireRenderFile, it does the output buffering stuff for you. $out .= wireRenderFile('./inc/training-item.inc', array('p' => $p));

Actually, @Robin S' approach isn't a bad one either. I've just pushed 0.0.8 to GitHub that overrides some native methods of FieldtypeDatetime and adds InputfieldDatetimeAdvanced to work around some explicit integer casts by the core WireDatetime class. I haven't been able to test it extensively yet, of course, but it does look like everything works on 3.0.34 (high time to upgrade my 3.x test system now). I'm not completely sure if the module upgrade will run smoothly. In the worst case, switch the field back to a regular Datetime field, uninstall the module and WireDT, then re-install the Fieldtype module.

Sorry, it's apparently been too long since I tested the module with newer PW versions (turned out I was using an early 3.x release, but too much has changed since then), but I'm working on it. It's giving me a bit of a headache still, but I'll try to have it fixed over the weekend.

Thanks for the feedback. I hadn't tried it with 3.x yet. Since WireDT is a PW module anyway, I'm going to switch to using PW's $modules/Module API instead of "new" and "instanceof".

You could try my DatetimeAdvanced field type and filter by showing_on.day_of_week.

Empty user_agent option in php.ini? Github sometimes (documentation says always, but experience tells it varies) blocks requests with empty or missing User-Agent header.

If you don't need the links as such in the source HTML, you could also consider using TextformatterMakeLinks.

Another strange Apache+mod_security issue perhaps?

Happy New Year too! getConfigInputfields is not the same as module configuration, it's a mechanism of the Inputfield class.

The waves div is fine for me. The images themselves do work as links, but my first instinct was to click the buttons below.