Leaderboard

At 1:49: me wearing a ProcessWire shirt https://it-gipfelblog.hpi-web.de/2015/05/17/alexandra-quiring-tegeder-ueber-schulische-bildung-im-bereich-it/

Btw.: I would like to see the wiki shut down to prevent confusion. The texts should be merged in the main site and tutorial section somehow.

Processbombing, surely!

Hi @AndreJansen. Welcome to the forums... There's also tutorials here: http://processwire.com/docs/tutorials/ and the 'Docs' section as well: http://processwire.com/docs/

Currently the 'Name format for children' setting is limited to: alphanumeric: 'test', will turn into 'test', 'test-2', 'test-3' etc. title: name will be based on the title once filled in (at first it will make the name 'unpublished', 'unpublished-2' etc.) date: the addition of any non alphanumeric character (including space) will cause it to be interpreted as date. So entering 'test more' will lead to some date string that doesn't make sense If possible i would like this to be made more fool-proof. But ideally i would like the 'Name format for children' to have more options. Like combining the different options and maybe be able to choose from more fields, apart from title. I also think that in cases where you want to auto-populate the name you often don't really care about the page title as well. So it would be cool if one could auto-populate a page title (and maybe other possible global required fields) as well. If the format would allow for date/timestamp, fieldvalues, text and combinations of those it would be really powerful. Also probably a lot of work but it's a wish-list after all

Not sure which forum category this should go in, but I spent my lunch break today training a few staff members of a pretty large client of mine on how to use a new processwire website I designed for them. They currently have a wordpress website and were dreading the training process. She said she didn't like how the wordpress widget system worked, and it was confusing to use. (Knowing where to go to update what.) After showing her how to use processwire, she said it was much more intuitive and user friendly. She likes how the page tree logically lays out the website, and how I designed their staff to be a page that other pages could read from so they only needed to update one spot. (Instead of typing it in to many different pages and widgets.) They gave it a big thumbs up! Just wanted to let you guys know!

Hi all, A client needs 12x languages on Processwire - I've set this up and it works beautifully out of the box. Again Processwire is wonderful thing. One thing they've asked for a way that languages are shown on fields on a per-user basis. This is so translators won't be able to accidentally edit the wrong language. So for example: A German translator will only be able to edit the German version of the fields. Is this be possible? I know that you can set a default language for each user, but could there be a way to set this and therefore restrict their access to one language only. Any help here would be massively appreciated as always. Thanks!

Is there a method to add markup to a single input field when building a form? At present I'd customise the forms markup: $form = $modules->get("InputfieldForm"); $form->setMarkup([ 'item_content' => "{out}<span class='custom-span'></span>", .... ]); Which works but adds the custom span to every inputFieldWrapper. Adjusting setMarkup on an individual field, i.e. $field = $modules->get("InputfieldText"); $field->setMarkup([ 'item_content' => "{out}<span class='different-span'></span>" ]); Calls the same method, setting $markup within inputFieldWrapper.php and adjusting the output of every inputFieldWrapper Therefore I was hoping for a way of appending to the inputfield or wrapper without it being global

Version 0.8.5 Add some more comments to FrontendUserRegisterEmailValidation module FrontendUser::auth() is now hookable (to build a auto login after sucessful user registration) Add usage shorthand to call login / register with one method call by set a second param ($redirect) // load module $fu = $modules->get('FrontendUser'); // login echo $fu->login(null, $redirectDestination); // with default fields //echo $fu->login(array('username', 'password', 'persist', 'forgot'), $redirectDestination); // load module $fu = $modules->get('FrontendUser'); // registration echo $fu->register(null, $redirectDestination); // with default fields //echo $fu->register(array('username', 'email', 'emailValidation', 'password'), $redirectDestination); The compatibility to PHP 5.3 seems to work fine, but isn't fully tested. Because Processwire 2.5 / 2.6 requires PHP 5.3+ I would't increase the requirements to PHP 5.4

No problem. If you send me the additional code and I have the time I could rewrite it to a hook. I would like to see the module used by the community and extended by hooks / plugins to keep the module core simple, clean and reusable Custom plugins could be added to my git repo / wiki to share with other PW users. I'm also interested in feedback if you use it inside a project. Just to see how it could be improved.

ok. Maybe a prepand / append to template problem? Could you check the config file? I load a custom template from module folder. Maybe I need another way to load it to prevent the template append / prepand... Updated module to 0.8.4 / email validation plugin to 0.0.2. module instance / object is now available via wire('fu') to simplify plugin hooks and... add PHP 5.3 compatibility Minimum tested at the moment! Could you test it and post the results here?

Hi Tom, I think the email template isn't loaded! Again a PHP 5.3 workaround is needed I have an idea how to fix it and make the module compatible to PHP 5.3. I'll update it soon!

Haha, you would be a great marketing face for PW

from the weird link from beluga.... what the |=uc|< - have stomach ache from laughter....but since this kind of text is branded in the web it's a little bit sad, too....

Hi guys, apologies for such a late response on this. I had to put this project on the backburner for a few months. cstevensjr – I installed the WireMailSmtp module, filled in the relevant fields and my tests are working now. pwired – Thanks for the response too. I don't doubt your solution would have helped but I tried cstevensjr's solution first and it worked. Thanks so much for the help folks, I appreciate it.

For example, set your links like this: kindheit/?order=1 kindheit/?order=2 and then set the order in your template file with $sanitizer->name($input->get->order)

wireshell 0.4.0 is out Big update with a lot of contributed commands and interfaces: "Module Download" command, extended "Module Enable" command, enhanced "User Create", added "User Delete", "User List" and "User Update" (thanks @justb3a). "Module Generate" command using modules.pw (thanks @nico), added "Status" command listing information on development, ProcessWire installation, image libraries (thanks @horst). wireshell's code and documentation were extended/cleaned up by @clsource. Also 0.4.0 introduced documentation microsite, wireshell Sorry, justbea and clsource, I seem to have messed up the PR's in a way that you aren't listed as project contributors on the GitHub page

just tried the comments fieldtype for the first time and it's great so far. but there's one thing: the link leads to "admin/page/edit/?id=1413" without the host. didn't find a configuration for that so i think the problem is somewhere else?

That's quite a specific need, I doubt that you'll find this ready-made. So either just use multiple mapmarker fields or multiple pages, or you'd most likely need to enhance the module by yourself so to store multiple values. If you go the latter route, than have a look at FieldtypeEvent. It shows quite nicely how one can make a fieldtype multivalue from an existing single value.

Ok so I got what I think is a workable solution... Installed Ryan's Page Edit Field Permission module Created 'language alternate field values' for each of my languages for each field, rather than using the multi-language fields. Added these fields as permissions using Ryan's module. Created roles for each language, so for example 'german_translator' role can only access the German alternate fields. It all seems to work well, and hopefully is pretty much exactly what the client was looking for in my first post.

Just got into Processwire and I am loving it so far, I am ready to start doing some more funky stuff now I have a basic understanding of it. At present I have a site where the client uploads XML files and image files to a directory they have FTP control over. Within their current CMS there is a link in admin to a PHP file which processes the XML files and puts data into a custom table outside of the CMS tables (therefore certain things cannot be controlled properly/well) so are not visible in admin. I have dived into the API and pretty sure this should be possible, and maybe even pretty easy, but where should I start? Creating a parent with a template, and then a template for the children with all the correct fields that I need?

With great power comes great responsivity Perhaps the risk could be minified adding some kind of confirmation, or requiring a checkbox to overwrite existing content.

This is great Craig, thanks. These guys certainly note the benefits of using their system via API rather than SMTP: Not tried their system but it looks good, like another Mandrill. The benefits of using Mandrill as an intermediary for sending email are many. For me, switching to Mandrill (using Horst's excellent Wire Mail SMTP module) meant that all emails got through—I no longer had occasional false spam fails.

Nice find, I am going to play around with it now and see what can be found...

I have this working as expected on a site I'm currently building, on 2.5.28 dev. Have you followed each step from the instructions?

Hi andre, welcome to the forums. You're right, it hasn't been updated for a while. I can't work on it right now, but would be great to have some help with it

Currently working on a html5 / js web app that turns an image into a pixelated version and found it simple to set up, on the back of this I could create a github version which is more about minimising size if someone else wants to spin it into a field type for PW. Lots more testing a to be done but looks positive. demo of what i have currently - https://dl.dropboxusercontent.com/u/608298/pixelator-gif.mov

I would suggest to include a delete button for images in the modal window of the editor. Today it is possible to upload images directly with the editor, but it is not possible to remove them in the modal window. So a delete button next to the upload button would be a great addition. At the moment it is only possible to delete an image at the image field. Best regards

How many times?

If I understand that right (never used any of those cms's / frameworks) than you should look at WireArray and WireData. These are the basic building blocks of ProcessWire and are basically the single and multi-entity data blocks. All other Datatypes build on this e.g.: User > Pagetype > Page > WireData PageArray > WireArray …. But I don't know of any specific "one to one" or "has many" relation, while "one to many" is just done by hierarchy (FieldtypeWrapper (Field) -> children (FieldsArray)).

That would be a welcome addition on my part too. If you add this request to GitHub let me know so I can vote on it.

I thought that new Avatar was some extremist uniform until I realised it was a Viking outfit. But I showed this post to a developer friend via Skype. The conversation went like this: Me: ProcessWire scalability (and link to thread) Friend: Impressive - ISIS must be very pleased with their dev Me: that's a beard ! Friend :oh, horns. obviously casual Friday

Thats not a beard, my chin just hit puberty

Thanks @mosid and @gebeer. Yes making a module should not be difficult. Anyway sometime ago I tried to including in the core. here's a repo with the PW fork that have Rest included. (its outdated) https://github.com/clsource/ProcessWire/tree/dev

Heads up for everyone, I just now updated the “stable” German language pack for 2.6.0, which – as usual by now – means a lot of work, mostly by Manfred, (translating all the things) followed by a little work by me (including a manual merge this time ). As usual, thanks to all the contributors, especially Manfred for his relentless efforts. Everyone, enjoy and please report anything you may find wrong or worth improving, ideally in a pull request at Edit: Yeah, URL would have been good, right? Report at https://github.com/yellowled/pw-lang-de, please.

Wow! Really awesome job there clsource. It really should be in processwire core as RESTful services is gaining attraction lately. What does ryan think about this?

This should do the trick! $f = $fields->get("body"); echo '<i class="fa '.$f->icon.'"></i>'; PS make sure you load this on the page: <link rel="stylesheet" href="/wire/templates-admin/styles/font-awesome/css/font-awesome.min.css" type="text/css">

Code before talk. With 2.5.0 released Friday, and 2.5.1 dev released today, there's been a lot of code.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

I'm not exactly sure what you're thinking "combine" means here, but this field does exactly what the description says; it grabs data from other fields, mashes it all together into one big blob of (JSON) content -- and that's just about it. One very simple (yet sometimes very practical) use case is if you've got, say, 15 different text fields and you need to find pages that contain value "john doe" in any of those. Instead of doing this: $john_does = $pages->find('field1|field2|field3|field4|field5|...|field15%="john doe"'); .. you can create a cache field, select all of those fields to be cached in it, and then do this: $john_does = $pages->find('my_cache_field%="john doe"'); Not only does this look clean, in certain situations it can wildly improve query performance.

I think procache gives you pretty much same end result. Of course there is htaccess enabled instead of direct folder/file mapping. Have you thought about that solution?

Thanks a bunch, diogo! I mean to say, {"text":"obrigado!"}