Soma

Page: https://sev-online.ch/de/members/login/ User: guest Error: Exception: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' (in /xxxx/wire/core/DatabaseQuery.php line 86) The first and only time I get this error on this site. It's on the login/register. I'm not sure what exactly causing it, but I'm sure there's some special char getting submitted? It's hard to tell just from the vaque error message. Any ideas how to reproduce it?

Once again I have to ask: Why is this a Process module? There's nothing in there that makes this should be a Process module. All it will do is clutter the process select list on admin pages for no reason. The version, as Ryan mentioned, should be 10 not 010. Leading zero's will make it read as octal, and octal 010 is 8.

Maybe activate the hidden formbuilder page for all languages. Not that if you use option c you'll have to add styles and scripts manually to your site.

If you use others finds on same page with limit, you need to add start=0 to the conflicting find.

I'm not positive you can have multiple pagination on one page

In my test PW needs 0.001s to load config and 0.1s to the point right before rendering a page.

@owzim, don't want to discourage you in any way, your doing great work here. Really enjoy seeing many others finally get more serious with module development, I know Ryan is, and I'm maybe just nit picking here. Yeah some good throughout documentation is a lot of work and I don't think I could pull it off. I did my contribution with the cheatsheet and that's already some work to keep it up to date, luckly enough it's now a ProcessWire site and can be managed some. With your module here while I don't understand all fully (haven't studied all nor installed yet), for example why you have config to the process module and on the textarea field (inputfield)? As per hook https://github.com/owzim/ProcessTextareaPreview/blob/dev/ProcessTextareaPreview.module#L120 Meanwhile you seem to have another config set in your process module too: public static function getModuleConfigInputfields(array $data) { return TextareaPreviewConfigHelper::renderForm($data, self::$defaultConfig); } But anyway, I think could that you're missing that the config is stored with the Field and not Inputfield? There's no storage for Inputfields, they're only for interface input and not DB. So like this you should get the custom data. $customFieldSettings = wire("fields")->get($inputfield->name)->customCssPath;

If there is a AutoPargraph textformatter you could also remotely use its function to convert it.

You could add a hook to FieldtypeTextarea::wakepValue() that is when loaded from db before rendered. Or convert it before you save with sleepValue(). Or in when youre processing the form and store it to a page.

I agree that there could be more documentation on that subject, but I doubt there will be very soon or never at all. These are quite advanced things you're trying to do, without maybe understanding it completely. I know how you feel and I recommend starting very small and experiment step by step try to understand what you're doing or what PW or PHP does. For some of these things , there's not always a "one" correct way. But one may lead to the wrong conclusions, as I had to recognize myself quite a lot. First understand PW modules and what they're for, like a Process module, a Wire or WireData module. How configs and local properties and PW data is handled and they're scope. I only now began to understand some of them. So don't ask me, and I doubt you'll get the right answer from anyone here except Ryan. Just and example, you can check if you're on a certain admin page using if($this->page->process == "ProcessPageEdit") but $this->process will return "ProcessPageView" Also things like in your Process module in the init first line there's: public function init() { parent::init(); // required parent::init(), isn't required at all here! Do you know what it does? It loads the styles and script using the same name as the Process module. Nothing else. SInce you don't have any styles or script associated there's no need to call this. No harm here either, just an example. I just think the module system in PW can be very simple or very hard, depending on what you want to achieve. I find it kinda worrying that so many modules get released, copied and looked at and things done wrong or misleading will not help others as they study your module and learn something wrong or not really correct. I'm no exception here. I know there's no way around that but also wish there should be a quality control (Ryan does some of it as I see) or a comprehensive documentation really. Butas I said this will take a long time seeing how long it takes to get on with documentation of PW and the API.

I'm not sure I can follow your code correctly. But you do add config to the process module and to the textareas inputfield config? I'd expected you only add additional config to the inputfield.

It's hard to follow what's going on in your modue and maybe it's just the order of how the hooks are called, but not sure. $this->addHookAfter('InputfieldTextarea::render', $this, 'hook_InputfieldTextarea_render'); $this->addHookAfter('ProcessPageEdit::execute', $this, 'hook_ProcessPageEdit_execute'); $this->addHookAfter('InputfieldTextarea::getConfigInputfields', function(HookEvent $event) { Also you're using a helper module in construct and in the config hook, I'm not sure what that does have an effect to that config system.

I think using a Process module here for this adding config is the problem, to start with. Process modules are meant for a specific thing. As I said it might work for every module you try to build but it's not the way to go I think, they should be used as such. The hook to add config should be done via a WireData autoload=true module.

Also I found after doing many modules that it often can get complex and you have to be careful with doing advanced stuff, it can easily break existing stuff. Sometimes just because it's working doesn't mean it's the correct way. But then it can often get very tricky since there's more than meets the eye. I always tried to look at ryan's modules and how certain things are solved. I think I understood most of this stuff, but even then I sometimes think I didn't at all.

This works fine when done right: see https://github.com/boundaryfunctions/TextareaCounter I'm not sure a process module is the right job for all those things you have now in a Process module that is loaded on every page edit even if no textarea preview is needed. I would have separated things more clearly. I might be wrong but I still thinking process modules should be used as such, not autoload and provide functionality that is bound to a admin page or admin url.

Kind boring sport you have here on earth. On my planet we also play a kind of "football", but it's called "airball". There's 42 players and the playing field is 3.1415 square kilometers. We use hover-boards and the ball is levitating. The goal is a circle and if the ball enters the goal, one player of the other team has to drink 1 cup of slime that contains 50% alcohol. Pretty damn fun. *hickup*

$pages->find("template=x, pagearrayfield=$somepage"); Where $somepage might be a page or a or multiples ID's . If $somepage is a page object, it will converted to a string with it's ID so you don't have to write $somepage->id but you could. $pages->find("template=x, pagearrayfield=1230"); $pages->find("template=x, pagearrayfield=1230|1233|1203");

Had to take a quick look to remember how I've done it. Thing is the modules is loaded but the ready() is never triggered in bootstrap and those language aware API is only added via hooks. So I did add those hooks in my script and delegate the event to the module manually. <?php include("index.php"); $lang = wire("languages")->get("default"); // manually add hook to use localUrl wire()->addHook("Page::localUrl", null, function($event){ wire("modules")->LanguageSupportPageNames->hookPageLocalUrl($event); }); // now works echo wire("pages")->get(1001)->localUrl($lang); // ------- // manually add hook to use user language wire()->addHookAfter("Page::path", null, function($event){ wire("modules")->LanguageSupportPageNames->hookPagePath($event); }); // now works wire("user")->language = $lang; echo wire("pages")->get(1001)->url;

In a bootstrap the Module isnt loaded but you can load it manually in your script. $user doesn't exist in a bootstrap. Use wire("user") instead.

5. It's in WireHttp WireHttp::download()

HelperFieldLinks add also a link to the template select field. http://modules.processwire.com/modules/helper-field-links/ I always thought and still think this should be something in core, but all we got is a hover on the field to show the field name as "text" appended to the label and only if in debug mode..

Great! This opens new possibilities to actually use markdown and alike. I was thinking a some time about having something like this, looks very nice.

ProcessGetVideoThumbs - it looks like this module is the cause and should be in the thread title. Maybe first enable debug mode in site/config.php and look what error it throws, or ask the ProcessGetVideoThumbs module thread.

I think we are not really done yet. You mentioned that those fields are page fields? Well if the values all are page fields, this means you know the all the values ahead. There's simple ways to get the distinct count using this reference. After all it's like a field relation from one page to another and PW can use that in selectors to find pages matching a page in selected in a page field. But this can be done in different ways and direction depending on what you need this can make a big difference. Loop all values for a page field and filter then count pages that matches (maybe not ideal in your case), or loop all pages and collect and count the values of fields, kinda what we were doing above. And others. On the last one if you are using page fields, you somehow only need to know the ID of the page selected to be able to count (got it?), but its value(!) is, as we know it is a selected page (Page object), so you also need to know the field that makes the value, the one you usually output. This is usually the title, but can be also any other field on that selected pages. After all you could even have your fields array, you define previous to loop them through, specify the field name for the "value" this field is using as value. Uff, does this still make sense? I'm not sure how your setup is and how you'll go about to define what fields, so again just an example code. Assuming your page fields are all single value selects (they'd have to be for this to make sense). $somePages = $pages->find("template=child-templates, somefield=somevalue"); $fieldsArray = ("province" => "title", "network" => "count"); // "fieldname" => "fieldname_onselectedpage" $result = array(); foreach($fieldsArray as $field => $subfield){ foreach($somePages as $p) { if(isset($result[$field][$p->$field->$subfield])) $result[$field][$p->$field->$subfield]++; else $result[$field][$p->$field->$subfield] = 1; } } So $p->$field->$subfield would translate to $p->province->title $p->network->count Which is the selected page's "title" or for the network field "count" (maybe an integer field). Looping through all values of a field in your case, since those are pages would mean to maybe also loop values that are not used at all in those pages. So maybe not always desired depending on the pro and cons, and maybe also amount of pages you deal with. I think in this case just try and see what happens, there should be no very noticeable slowdown if you run this code until let's say 10 fields over 500 pages or 2-3 fields over 1000 pages. Hard to say out of the blue. If there's a lot more that need to be looped, I think you would need to consider some other direct sql queries ($db->query("SQLSTATEMENT"), $database->query("PDOSTATEMENT") On a sidenote I find it more and more very hard to commuicate such "complex" thing just for the terminology of all the things, like pages, selected pages, fields when having to deal with page arrays and page fields. I never know if the other person understands the same. Anyway.