Leaderboard

No problem. I had to do someting with my 1000th post

Welcome to the forums, Mick! Sure you can do it. Look through these links: PW API way - http://processwire.com/api/include/ Web service way - GrapQL way -

There were a few talks about user avatars here on the forums. Like it means something. I never thought it does. But today I suddenly realized how far the right avatar can take you. I was just testing something in the incognito mode in chrome and... here he is, mr. @kongondo himself! I know, I know, you can say it is only someone that closely resembles @kongondo, but does it matter? If he could make it into my subconscious that far, he could easily penetrate the browser .

I just ran into this and thought you guys might like it as well as it seems like a really useful tool to me! It's called Kite and is still in beta, but in the end should be working with your editor of choice. Check out this video on youtube.

A little more info from Ryan on why it is appearing to be huge when dumped: the _wire reference present in every Wire derived object points to the current ProcessWire (class) instance. Because the ProcessWire class extends Wire, that means it also has a _wire property, and that property in turn points back to the ProcessWire instance. That's not inherently a problem, and it's necessary for access to API variables by all Wire-derived objects. This is one of the means by which we support multiple instances of PW. There is no recursion unless some code tries to follow the protected _wire property of the protected _wire variable. In addition to the getArray() that kixe mentioned, also check out getIterator() and be sure to try the TracyDebugger module for dumping objects/arrays.

If RemoveButton is not false then show the button: <?php if (!$single->RemoveButton) : ?> <p><a button href="<?= $single->url ?>" type="submit" id="submit" class="btn btn-blue btn-effect"><?=$single->Text?></button></a></p> <?php endif; ?>

For the topic how to import / batchimport content into PW you will find many posts with examples in the forums, - so I will focus on your special issue with your images that are linked to "./images/...." in your htmlContent. Assumed, you use an importer script, that reads the following from a source: title / name of an entry html content images basenames Assumed, that the importer script can access the imagefiles / knows where they are kept for the import. And assumed that you have created a template with fields for those pages you want to create during the import. Then you will come to a point, where you programatically create a new page: $p = new Page($myTemplateObject); $p->of(false); $p->title = $theEntryTitle; $p->parent = $theParentContainerPage; $p->save(); Now you can add / import your images to an imagefield: foreach($imagebasenameArray as $basename) { $p->imagefield->add($directorypathToImages . $basename); } Now all images of that entry resides in /site/assets/files/{PAGE_ID}/. And you have to modify your html-content to match this: $p->body = str_replace("./images/", $config->urls->files . $p->id . "/", $htmlContent); $p->save(); This way you will have the most possible flexibility with your pages, I think. Please note: written in the browser, - may have bugs, - is meant as pseudo code.

Hi. I also needed a solution for Images Pagination and came up with this solution. It only works on PW 3 with the new PaginatedArray class. My Situation: I have a image field with about 150 images. I want to output these Images with a PagerNav. The same i use on $pages->find(). This is the function wich I wrote to get this working for PageImages. /** * Renders a pagination based on files using the PaginatedArray Class. Overrides the input parameter $files with the sliced result * and returns the rendered pagination. * @param $files ... the full Pageimages WireArray * @param int $perPage ... items per Page * @param $pagerOptions ... standard Pager Options as used in MarkupPagerNav.module * @return string ... rendered pagination */ public function renderFilePagination(&$files,$perPage=10,$pagerOptions) { $total = count($files); if($total <= $perPage) return ''; $pagerArray = new PaginatedArray(); $pagerArray->setLimit($perPage); $pagerArray->setTotal($total); $pagerArray->setStart(($this->input->pageNum - 1) * $perPage); $pagerArray->import($files->slice($pagerArray->getStart(), $pagerArray->getLimit())); $files = $pagerArray; // overwrite $files $ret = '<div class="paginationInfo uk-text-center uk-text-small uk-margin-top">'.$pagerArray->getPaginationString().'</div>'; $ret .= $this->modules->MarkupPagerNav->render($pagerArray,$pagerOptions); return $ret; } This function has to be available in your template files. Perhaps you need to remove the public. I am using it in in a custom module. Now in your template file you have your images field for ex.: $page->images (multiple Images). You can call the function like this: $pagination = $modules->KaTemplateHelper->renderFilePagination($page->images,$perPage=40,array( 'listMarkup' => '<ul class="uk-pagination">{out}</ul>', 'itemMarkup' => "\n\t<li class=\"{class}\">{out}</li>", 'linkMarkup' => '<a href="{url}"><span>{out}</span></a>', 'currentLinkMarkup' => '<span>{out}</span>', 'currentItemClass' => 'uk-active', 'nextItemLabel' => '»', 'previousItemLabel' => '«' )); The third array parameter is completely optional. I only use it for changing the standard page nav markup. If you use the standard markup then call: $pagination = $modules->KaTemplateHelper->renderFilePagination($page->images,40); ----------------------- After the call: $page->images only contains the subset wich will be display on this page. $pagination contains the rendered HTML Markup for $pagination. Perhaps this helps someone. I know this is not fully flexible implemented, but this is only a snipped for me that I change as i need it.

To be more explicit: See this codepen.

This module (http://modules.processwire.com/modules/import-external-images/) works for images embedded into HTML with full http urls, bit should be easy to modify to support a local path instead.

+1 of course, but if you need something more general, there are other solutions, such as: https://github.com/leeoniya/dump_r.php highlights from its readme:: "$depth sets the recursion limit for the dump" "Circular reference (recursion) detection and duplicate output is indicated like this for arrays, objects, closures and resources respectively: [*],{*},(*),<*>."

It is normal to be logged out after the browser session is closed. You can use the LoginPersist module if you want to stay logged in across sessions.

What rendering issues do you mean? The problem is that you cannot measure performance in printing out objects. If objects contain a lot of references to other objects, this may take time to print out. In terms of page types, you have references to other pages and there may be a recursion problem, e.g. print a parent page with references to its children pages, each child page has again a reference to the parent) etc. The Page field is one main features in ProcessWire, at least for me. It makes the whole system powerful in terms of data modeling. If you want to measure performance, you should do it right, for example with a PHP profiler. Btw I'm also fan of clean code and good performance, that's why I'm working with ProcessWire Cheers

This morning, after some adjustments and tests, the module run smoothly on ProcessWire 2.7, 2.8 and 3.x.

Here is very simple abstract class that I hope would get ideas and contribution from community, so that different PW projects could use same payments methods in generic way: https://github.com/apeisa/Payment Currently Payment modules just assume it's found from /site/modules/Payment/Payment.php, but I would love to get it autoloaded somehow (I went with PW module dependencies and transformed the base class into PW module also). Also I have tried to keep this as minimum as possible - hopefully I have not left anything too important out. I have also created one two payment modules, that use this base class: https://github.com/apeisa/PaymentStripe/ https://github.com/apeisa/PaymentPaypal/ Please visit their repos for examples.

Hi all. For a while now been wondering how many would be interested in a backend and frontend shop catalogue built on top of PadLoper? I've previously spoken to @apeisa about this and his take is that there are no plans to develop PadLoper in this direction but he's happy to support such efforts. The gist of the backend shop catalogue is to provide one place (think ProcessModule) where you can manage your PadLoper products - add, edit, delete, track sales, etc without having to set up the underlying structure yourself. The frontend would be like a shop/webstore profile, a frontend cart basically, that's customisable. The shop would be 100% powered by PadLoper. This means that to use the 'shop catalogue' would require that PadLoper is installed. These are just loose ideas at the moment for a pro module. This might or might not see the light of day depending on feedback. Anyway, would love to hear thoughts, thanks.

As fas as I know, currently there is no way for a module developer to include a changelog in a way that enables us to check out the changes in the admin before upgrading.

Just be careful not to build a mystery meat navigation.

@kongondo Whatever you saw that wasn't me

Hahaha Ivan, you've made my day!

You can put three links inside a div and make them squares with css.

Funny, today I went to something very similar with another avatar from this forum

Awesome! Thanks Ivan!

It is all easily done with a script which bootstraps PW as shown above using api. The implementation depends only on where you are going to import from - a csv, xml or maybe from a remote database on cron to be always synchronized. There are tons of good examples on the forums. This is just a most recent one which is currently being answered. If you'd rather use a gui module, there is one.

Hehe, congrats for 1001! R

Did you build this whole thing with processwire or is it an add-on from somewhere? I like the idea of this. Thanks.

No problem. Just as you post your ideas I can post my concerns.

Seems your new server does not have the PHP extension DOMDocument installed. Ask your host to install it for you.

For debugging you could use print_r($page->fieldtypePage->getArray());

@Robin S Thanks for pointing this out. I agree and changed the 3d argument. It receives now the row related to the value. ATTENTION: Since Module version 1.3.5 you have access to all row columns as described here wire()->addHookAfter('FieldtypeSelectExtOption::label', null, function ($e) { $optionLabel = $e->arguments[0]; $optionValue = $e->arguments[1]; $page = $e->arguments[2]; $field = $e->arguments[3]; $row = $e->object->row($field->name, "id=$page->id"); }); /** * select field for images in a multilanguage environment * label pulled from image description in default language with fallback to filename */ $this->addHookAfter('FieldtypeSelectExtOption::label', function ($e) { $array = json_decode($e->return, true); $page = $e->arguments[2]; $field = $e->arguments[3]; $row = $e->object->row($field->name, "id=$page->id"); $e->return = $array[0]? $e->return = $array[0]: $row['data']; });

Some basics when working in OO software. If you print_r() a object (ie page or field), PHP will traverse the object (try to) and load all its references recursively. It unfolds the object which isn't really present in the original object and only loaded or accesses it if you would do call stuff on this object. This doesn't mean the object contains all the stuff you see printed at that time before you call print_r(). Edit: Oh a page field contains only a reference (by the id) to the page and loads the page object and not even its content unless you call it (except autojoin fields).

I agree with you, I was just trying to think of a way to freely act over the elements. Sorry for this crazy post ;-)

The Pager includes prev and next links with identifying classes in the markup when there is a prev and next page to the results. Use CSS to position those links where you want them to be. .MarkupPagerNavPrevious { } .MarkupPagerNavNext { }

As someone maintaining a project with lots of different frontend templates I'd imagine you'd get into trouble way fast with such an approach. As soon as you've more than a few of those calls in your code base it'll get hard to reason about what's currently visible and what's not part of the markup, as you've to go through all those steps in your head. There's no scope of interaction. Each of those calls could potentially change everything in your page. I don't think it's a good idea to let you junior dev remove some class in some part of your website, which by accident could break other parts of it because the class is duplicated. With the current markup implementation you're at least bound to a (hopefully limited) number of named regions. I imagine it a bit like those early jquery webapp javascript files: a mess of spaghetti code which nobody but the creator can understand in a reasonable timeframe.

I just tested this using the "Text List" and "JSON settings" options and it should now work with Core modules as well, but it's not well tested, so please let me know how it goes.

I wasn't aware that the field settings are inherited in the ckeditor dialog, but I should have suspected it. What should work though is adding another image field at the bottom of the template, then going to Modules -> Configure ->ProcessPageEditImageSelect and adding the name of your gallery field where it reads "Field names to skip for selection".

I haven't tested, but maybe this helps: https://github.com/somatonic/ColorPicker/issues/7

@adrian I am thrilled by your suggestion and would give it a try once the main functionality is achieved. For the moment both the ingredients and Cooking instructions were completed using a textarea field with 1 ingredient per line. Here is the code in case somebody needs it: <ul class="ingredients"> <?php foreach(explode("\n", $page->recipe_ingredients) as $ingredient) { // Explode function is to get the value before Enter key $incr = $incr + 1; // Increment is used for the checkbox ?> <li> <input id="check-<?=$incr;?>" type="checkbox" name="check" value="check-<?=$incr;?>"> <label itemprop="ingredients" for="check-<?=$incr;?>"><?=$ingredient;?></label> </li> <? } ?> </ul>

As adrian pointed out, in multilanguage environment you have to put setlocale() in init.php, ready.php or admin.php since language support module will overwrite locale settings in config.php. Still waiting for response from Ryan about that.

I would also love to see this - I think it would be great if we could define it in a Github repo changelog.md file and have the automatically imported into the text in the modules directory, and perhaps even displayed in the module info within a PW install. Perhaps it would even be nice to have a way to add a flag about breaking changes that would show up in the ProcessWire Upgrades module so you are warned before upgrading. @ryan - any thoughts on this? I'd be happy to work on it - obviously I could do the PW side of it from the repo, but would need access to the php files for the modules directory to make that side of things work.

FYI - I had to add it to init.php on certain servers: https://github.com/processwire/processwire-issues/issues/184#issuecomment-280079855

I'd add it to the config just because to me a locale is like a config value. init.php might be a little late because auto load modules are already initialized https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/

Exactly! Thank You!

hi, it's not possible (out of the box) to use a plain form instead of the render() tag. The processing of the form includes several error checks and a lot of additional logic. I solved it this way because my experience has shown that it's really difficult to support plain html. Most users break the form which leads to increased overhead. I'm not a fan of generated content therefore I added all possible options to customize the output. How did you add the content above the form? Do you use the option `prependMarkup`? If the content above is still there after submitting the form, this is ProcessWire Core behaviour I don't want to change. Just use `display: none` to hide the content (there should be a parent element containing a class which indicates that the form has been submitted successfully. If not, please let me know, I'll add such a class).

That's the exact thing I try to avoid @Marvin: Here goes: https://github.com/sforsman/SessionLdapAuth I even added an example for the group mapper and did a modification to the code (well, I fixed a spelling error in the description of the module)! If you have any questions about some parts of it, just ask away. I've published it as a Proof of Concept. (see Nico, I'm learning!) No but really, the main point here is to give you something to think against regarding your own implementation. The group mapper configuration string for an example is parsed in a very quick and dirty (=error prone) way and shouldn't be given directly to clients.

In case anyone is interested in trying out some of the things I was talking about in previous posts here, the latest dev branch has a field import/export function. You'll see it in the lower right corner of Setup > Fields. It enables you to copy and paste any fields across any PW installations. Locally, I also have this working for templates (with fieldgroups), though that part needs a little more work so it's not yet committed. I also have fields, templates and fieldgroups mirroring every change to JSON files, as an option that can be enabled for those that want to version these things with Git and what not. That part also isn't yet committed to dev, but will be soon. However, I figured the copy/paste function probably had the largest use potential. It makes migrating field changes (or creation of new fields) quite a simple task. Next up on the commits will be the same thing for templates (with fieldgroups). (note I didn't take these screenshots together, so they aren't referencing the same fields).

Today the german "Webkrauts" published an article by Michael van Laar about PW in their advent calendar: http://webkrauts.de/...012/processwire I think by tomorrow the new revision of a german podcast called "Working Draft" will be published where I talked over 20 minutes about PW. And here it is: http://workingdraft.de/99/ [everything in german, sorry]

Actually, that's not a review--that's our marketing copy. Looks like they copied and pasted it from these two pages: http://processwire.com/about/what/ http://processwire.com/about/why/ We allow this usage with our press releases, but not with our site copy. The ProcessWire site copy is not open source, so whoever posted this should have asked for permission before doing so.