Leaderboard

You can create multiple user templates, since 2.5.14 (https://processwire.com/blog/posts/processwire-core-updates-2.5.14/). I'd use them.

Sweet! yes my date field is called news_date. Thanks again. Processwire looks interesting. Thanks again for your quick response.

When the user specific data does'nt have to be queryable / searchable on database level, all you might need is a textarea field in which you put a JSON object with all the data. Then JSON encode the data that the user submitted, save it to the textarea, and when fetching the data JSON decode it to have it available in an Array or Object. When you want to be able to query / search / filter directly on database level or have huge amounts of data this aproach might not fit your needs. Although as soon you have a JSON decoded object retreived from the database you can search / filter using the API, but then it is all done in memory instead of the on database level.

Want to use Mandrill for sending emails using their HTTP API rather than SMTP? Read on! I've been working on a WireMailMandrill module for a site I'm currently adding some features to. So far, the module has been tested for simple mail sending, with basic options, and attachments. I haven't tested the full range of things that are possible with the official Mandrill PHP library, but I think I've implemented the ability to set most, if not all, of them. This should be considered beta and not entirely relied upon for sites in production. Testing and feedback welcome. I'm sorry about the lack of code comments at the moment as well, I was just throwing this together as I went along so I could move onto the next part of what I was building... This was originally mentioned in a discussion about SendGrid and Mandrill options in a thread in the Form Builder support area. Not everyone has access to that, which is why I'm putting this here WireMailMandrill on GitHub Quick example (taken directly from a site I'm working on): $mail = wireMail(); $mail->from('info@example.com', 'ExampleCOM Enterprises'); $mail->to($toMail, $toName); $mail->subject('Entry confirmation'); $mail->bodyHTML($bodyHTML); $mail->attachment($myPage->files->first()->filename); $count = $mail->send();

Hi guys, Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes. I'm not a developer so making these a reality is impossible for me. They're flat designs. Why? PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed. 1A. Current Image Modal Editor has clicked 'Add image' icon in CK editor. Issues: I believe the Upload Image button can be better placed. It's not clear to users that they have a choice of two actions (Select an Image OR Upload one) To help solve this, I thought we could: Place available images under a Choose tab Create another tab titled Upload Rename modal to just Image (from Select Image) tweak slightly the Images on page path to be less prominent The following image illustrates the result. Clicking the Upload tab would result in: In the above image I've created toggle-able accordians for Drag and Drop and Manual upload. This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent. 1B. Alternative to above - combined Select and Drag/Drop I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping. 1C. The Image field I then moved onto looking at the Image field in PW. So currently it looks like this (below) for a simple image field called Image Gallery. So although the current Image field works great, I wondered if there was a way to simplify it by Making the drag/drop more visual and obvious Moving the Choose Files button and removing the No file chosen text and the file types allowed Here's the result. Admittedly, this treatment adds more height to the overall field. Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text. To be honest, I can't recall what other changes I made there! And here's a proposed layout for when there are multiple images. This includes image titles grid layout mouse-over for edit and delete options/buttons 2. Cropping Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. So heres the current layout (this may have changed further recently) And here's my proposal. Changes are: Width, height and X and Y fields are moved below the image Apply and Cancel placed bottom right of the image Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options Save and Replace should be greyed out further In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side). Forgive the croptions label (Crop + Options pun - I was tired!) The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI. Presets (on right) could be a few out-of-the-box presets which come natively. Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display.. That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

Does your news template have a datetime field called "date" assigned? Maybe you named it differently?

Make sure that the script creating the pages is also UTF-8 encoded.

Hi uuragoda, Welcome to the World of ProcessWire, enjoy! Now to your question: You are limiting the number of news entries to twelfe. Could it be the case that there are more than 12 items? Maybe you're just missing sorting the news entries, e.g. by a date field or by the native created field: $items = $pages->find("parent=/about/newsroom, limit=12, sort=-created"); // Get the latest news by created date, descendant sorting

I would also check database setting: database character encoding should be utf-8 template files need to be utf-8 encoded HTML-Output need to be utf-8 encoded (header)

Easy answer: PW uses the MyISAM storage engine, which does not support foreign key constraints. InnoDB could be considered at some point because it has some benefits and also full text search for a while now. But to my knowledge MyISAM still outperforms InnoDB in some areas and there are more things to consider.

If xml is simple enough it should work. If there are attributes etc it will fail. Maybe I should finish this. Thinking of making one version for json and another for xml. Or better yet, making these and csv importer working in harmony (sharing some bits of code like mapping etc).