adrian

Could be as simple as a page load, but clearing the PW cache couldn't hurt. Might also be worth clearing the file compiler cache to make sure everything is regenerated.

Did you upgrade from PW 2 to 3? Maybe reload again - that new error sounds like a file compiler issue - I have noticed that occasionally you need an extra reload to trigger everything the first time to upgrade to 3.

I just did a quick test with BCE using your test file and by the time it hit my 120 timeout, it had created 4898 pages, so 2449 pages per minute isn't too bad. Curious what you find at your end though.

Hi Steve, Are you talking about PHP's session folder, or PW's /site/assets/sessions/ ? For the former, should PHP's garbage collection take care of that? For the latter, I see I have a few (5) old "tracy.0e3b49e668" files from Apr and May 2016, but none more recent. I wonder if this is an old issue that has been fixed. It sounds like you are still seeing new additions though? Could you provide more details on the age of these files, and also your OS, PHP version, etc? Thanks!

Might be as simple as file permissions - do a recursive 755 / 644 (or whatever is appropriate) and make sure the owner is correct, eg www-data:www-data

Less fields is better for you - less to manage, but it won't matter to PW either way because all the field db tables (eg field_slider) are indexed by the pages_id so PW finds the relevant entries very quickly. Having a separate field won't improve this.

As I mentioned - I think this may have been due to a change in the default settings of MySQL in more recent versions. Surely you can understand that 2.7 was working at the time when most of us were on older versions of MySQL? Out of curiosity, I googled Drupal and Wordpress along with the "column not found" error and found many results. Not trying to make excuses - just saying that this is sometimes the reality of software development - things break due to changes in dependencies - there are a lot of combinations/permutations to keep up with!

I haven't used this module, so not sure about those red fields, but I think the likely correct fix for the operator not supported issue is to to define $allfields in the additional fields at around line 65. protected $allFields = array();

I completely understand your concerns regarding giving a client a product that you don't have faith in, but there should be no way a client can make this happen - they should not be given superuser access and therefore should not be able to install modules. I made exactly the same argument as you some time ago I just forced the same error in PW 3 (by deleting a language field in the pages table) and it now looks like this, with everything still accessible. I would definitely urge you to try PW 3 - there has been well over a year of development that's gone into this new major version. I think it is only fair that you judge PW based on this version - I hope you agree!

Just wanted to follow up by saying that when you're running an old version of software, things like this can happen due to changes in dependencies. I know that your issue has come up in the past: https://github.com/ryancramerdesign/ProcessWire/issues/957 and was fixed at the time. I am not sure if your version is possibly from before this fix or not, but regardless there have been some relatively recent changes to the default settings in new MySQL versions that have had similar effects, so it pays to always install the current stable version.

Sorry you had a bad experience with languages. A couple of things here: 1) What version of 2.7 are you running - make sure it is 2.7.3 2) 2.7 is pretty old now - you should be running 2.8 or 3.x - both have many fixes since 2.7 3 ) This should be an easy fix - just add a new field to the "pages" database table called "name1022" with these settings: varchar(128) ascii_general_ci null = yes Hope that helps!

Of course, I wasn't thinking - I have done the same thing myself on occasion

Maybe I am confused here, but I think you want the following - you have to get the comments from a given page - obviously in this case, the current one ($page) $latest_comments = $page->comments->find("limit=5, sort=-created"); echo $latest_comments->render(); or translated to: $letzte_kommentare = $page->kommentare->find("limit=5, sort=-created"); echo $letzte_kommentare->render();

Surely if it's a count operation then you could just subtract the number of pages that need to be excluded - no need to add them to the selector. Or is count() just an example and you do actually need to return the pages?

The approach is fine, just a couple of minor problems, one being the if($img) conditional. The others are the "return" at the end of the first couple of checks that are exiting right there. Try this: <?php /** * Module for generating Gravatar URLs for ProcessWire users. * * Use it like this: * * Get URL only with all defaults: * $user->gravatar() * * Get image tag with different size: * $user->gravatar(array('img' => true, 's' => 200)); * */ class Gravatar extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Gravatar', 'version' => 1, 'summary' => 'Gravatar hook for users', 'singular' => true, 'autoload' => true, 'icon' => 'smile-o', ); } public function init() { $this->addHook('User::gravatar', $this, 'methodGravatar'); } public function methodGravatar($event) { $u = $event->object; if ( ! $u instanceof User) return; if ( ! $u->email) return; $params = ($event->arguments(0) ? $event->arguments(0) : array()); // Default options $defaults = array( 's' => 100, 'd' => 'retro', 'r' => 'g', 'img' => false, 'attrs' => array(), ); $opts = array_merge($defaults, $params); extract($opts); $url = '//www.gravatar.com/avatar/'; $url .= md5(strtolower(trim($u->email))); $url .= "?s=$s&d=$d&r=$r"; $url = '<img src="' . $url . '"'; foreach ($attrs as $key => $val ) { $url .= ' ' . $key . '="' . $val . '"'; } $url .= ' />'; $event->return = $url; } }

It looks like: if ($img) { is preventing the $url from being defined.

Try $users instead - that should work with non-superusers. $event->users->find('roles=client');

Rather than trying to hack the url for file_get_contents, you should use ->filename instead and then you can just do: file_get_contents($page->icon->filename);

Actually I take that back - the function (and therefore the db query) won't be called unless you call $page->courseData so no need for this.

You will likely want to add some sort of conditional inside that AddHookProperty to check the template of the page so you only run the query on appropriate pages. eg.: if($event->object->template == "template_that_needs_course_data") {

will give an "Array to string conversion on line: 3" error. In Tracy you can dump the array with d(), but in your template code you will likely want to leave off the ->each("title") and foreach through $sayfalar to return various fields.

You can add a hook like this in your /site/init.php file: $this->wire()->addHookProperty('Page::courseData', null, function($event) { $sql = "SELECT * FROM ......"; $results = $this->wire('database')->query($sql); $event->return = $results->fetchAll(); }); And then in your template file you can call: $page->courseData You can also make of $event->object->name inside the hook to get the name of the page that the courseData property is called from so you can use that in your sql query. Of course you can get any other field from the page, like $event->object->myfieldname and use that in your query as well. Does that help?

"how to store it inside processwire" - I am not sure what you mean here - do you mean save the content to PW pages? You can query content from an external database and simply iterate over it and output in your template file. Here is the docs on $database: https://processwire.com/api/ref/database/ Here is a rough idea of what you can do. Obviously I am querying the PW "pages" table, but you can do this on any table in the database whether PW or not. You can see in the output that you can easily iterate through each row in the returned array and grab whatever array keys (db fields) you want.

You can easily make use of PW's $database to call an external database to populate content on a page - nothing fancy and no hooks required. It might help if you can provide more details of the data in these tables and how you want it displayed.

@Beluga - are those massive execution times with BCE or Ryan's module? I am using a third party csv parser - I don't think its approach is very efficient, but php's built-in parser is crap when it comes to certain situations. There might be better options out there though. BCE doesn't make any SQL queries directly so not sure any of those mentioned tweaks would be any use. Also given that in PW each field has its own table I don't know how you could make use of LOAD DATA INFILE etc because you'd have to do a lot of data manipulation before inserting so that you were populating one table at a time with all required data - sounds like a real likelyhood of introducing data integrity problems. That said, if you find something that makes a dramatic difference, please let us know.