Leaderboard

roger.that is possibile

Hi Guys, I created a new module to optimize jpegs using the command line tool jpegoptim which yields amazing results, it's comparable to jpegmini.com when using 75 quality. Instructions and usage are available in the readme on github. https://github.com/jdart/JpegOptimImage Let me know what you think! Thanks

Aah, this now seems to be a slightly different question. What you are asking is about 'structuring' - the HTML...rather than 'styling'...the CSS, or maybe both? ... How comfortable are you with HTML, CSS, PHP? The first two you definitely need to know, the third you need to know the basics. Answers to this will determine how much re-structuring you can do, especially with the 'work-horse' that is the Blog Profile. If it was just about styling, the place to start is to fire up Firebug (if in FF) or Chrome developer to examine the HTML output of the rendered Blog pages, note the names of the CSS ids and classes and the relevant lines in the CSS files where you need to make changes. Then you can change those as you wish (but you might want to do a back-up of the CSS file first). Ideally, you should be working locally first before uploading to the live site. If on the other hand you want to add things and move things around, you will need to dig into the code. Now, the Blog Profile uses some relatively advanced code and has all sorts of includes coming in from different files some of which also include other files, etc...Unless you are comfortable with PHP and ProcessWire API, I am afraid you will struggle. If you are willing to learn PHP (at least the basics) that is great and will serve you beyond ProcessWire if need be ....So, I can point you to look at main.inc and blog.inc (/site/templates/) since that is where the main magic happens, the former mainly for outputting stuff and the latter the engine room serving different things to main.inc, but it would not help you much if you were not comfortable with PHP and PW API. Having said that, I am not in any way trying to discourage you. I am just recommending that you try and get the PW basics first (if you haven't done so already)...and the road ahead will be less bumpy ....

You think that's cool - check out the new "Pages > Find" functionality which makes use of Lister, which is now available in the latest dev 2.4.4 PS, the new Users section uses Lister too

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.

Netcarver, ProcessDiagnostics is beautiful–really enjoying it. I have one suggestion though, which is to either have ProcessDiagnostics install at least one of the diagnostic modules, or to have it display some error if none are installed when you go to Setup > Diagnostics. I tested on a new installation this morning (before I had my coffee) and couldn't figure out why I was getting a blank admin screen when viewing the Diagnostics page. After hunting around in the code trying to figure out why, I eventually slapped myself for forgetting to install any of the related Diagnose modules. But I'm guessing other people might run into the same thing.

@kongondo so explicit in your feedback and i love your approach, am getting to know things better. i am really comfortable with PHP, CSS AND HTML and with what you just explain now i will do the experiment and get back and i know how to work with the developer tools in FIREFOX OR BUG. I am really grateful for your support and all those who contributed. making sense.

Two new small sites, both powered by PW 2.4. Both of them in German only (sorry, people who can't read German), HTML5 and responsive. Both kind of simple in design (per request). http://www.eutin-immobilien.de is a site for a local real-estate agent (in a very small town). Content's become a bit weird since the client started to manage it himself because he used the wrong image formats here and there and also decided to skip my advice to keep the headlines short. Nothing much I can do about that; at some point, you just got to let it go. (I'm not a huge fan of limiting the number of characters there.) http://clic-deutschland.de is for a small, but expanding association which … well, I guess it's best described as a network of support groups for addiction. Kind of like AA, but with a different approach. Especially challenging since they have extremely weird needs in terms of the date formats for their events. Excellent example of how to use the GoogleMap marker module with a jQuery plugin to make it really easy for editors to add individual maps for directions. (The latter was originally requested as a Wordpress site. I suggested PW instead, and the main editor is so impressed by PW that she's considering it for the next relaunch of her own web site.)

Tomorrow we are going to enjoy 3fingers VS Kongondo (Italy VS England)! Forza Azzurri!

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.

Joey102030 Thanks for your contribution to the development of this module. I've updated the version number to 1.0.2. It is already in the master branch.

Ha ha - good one Martijn. Yes I may live in Spain (17 years now) but I will always stay a Dutch guy I always put my bets without doubt on the Netherlands when it comes to football. Talking about it, I am not the only Dutch guy here. Heck there are even lots of dutch bars and restaurants here. I have learned to know lots of dutch people here. We always read dutch newspapers to know what is going on in "Holland" and have long discussions. Spanish locals call us "cabezas de queso" which means "kaaskoppen". In some dutch bars here dutch people now show up with orange wooden shoes which are "klompen" in orange color specially for the Dutch - Spanish football. It is going to be a long orange week-end here

Something like this should work... $t = $templates->get('basic-page');//get the template $f = $t->fieldgroup->getField('summary', true);//get the field in context of this template $f->description = "This should be the description";//value of the field $fields->saveFieldgroupContext($f, $t->fieldgroup);//save new setting in context Edited for clarity... In this example, we are changing the description of the field 'summary' in the context of the template 'basic-page'.

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

Hi I would like to share with you my first module. Module integrates PixlrEditor with a InputfieldImage. You can easily edit your images online. The module provides a link to edit each field type InputfieldImage. Have fun;) Warning: I have not tested yet on localhost. As Ryan pointed out. It does not work on localhost. Pixlr webservice must have the ability to get images from your server. Source: https://github.com/P...GIX/PixlrEditor Screenshots: Changelog 1.0.2Now Support Thumbnails Module - Thanks to joey102030 for the addition.

Playing around with the markup cache on a website which is listing accommodation/activities. The page in question displays a number of listings (info about accommodation operator) and then a google map with markers for all the listings. I've cached (using markup cache) each listing, and also the google map markers, and the performance boost from this is pretty damn good, I'm stoked with the result. In the process I've got a bit obsessed with page-load speed and done some benchmarks. the following image is a sample page-load. The troubling aspect is time PW takes to get up and running. As you can see from the benchmarking info the vast majority of page-load time is PW startup - that is everything prior to the page template - ie, the time is measured from the start of index.php to the start the the page template file. Is this normal? This is on a live server (shared host) and the value varies from 400-600ms. Do installed modules have any impact on this? Is there any way to speed this up? It's reasonably snappy but if this can be improved then I'm all for it

OK, ladies & gents. If you are interested in or have been 'forced' to watch football (that's soccer for y'all across the pond)....here's a thread where we can all discuss all matters World Cup 2014 in one place. Predictions, Best, Worst moments, Favourites, Anecdotes...bring it on please!

Short tip Use the ajax powered search to find pages you want to edit—it's a super-fast way to get around the admin. Longer (but same) tip I was on the cusp of not writing this because it is likely so obvious to so many, but just in case you are like me in terms of navigation in the Admin for editing pages... In PW 2.4 the new search makes finding pages lightening fast. While some themes from before 2.4 was released display recently edited pages to help speed navigation, the new default theme in 2,4 doesn't; and I missed that a bit. But the new search is super fast so now whenever and wherever I am in the Admin, if I want to edit a page I just type in the search box, it ajax-pops, one click and I'm in the page ready to edit—no need to visit the page tree Thanks to Ryan and crew for this small but great advance OK, back to work.

@Ryan Just pushed a fix - thank you. @GuruMeditation Glad nothing imploded. @adrian I've removed ENT_HTML5 - thank you. After reading up on optimize I'm not sure I'd want to perform it on all my tables - especially on large InnoDB tables (InnoDB support is gradually creeping into PW.) I'll think about this a little longer before deciding if I'm going to add it but thanks for registering your up-vote.

Thanks again for this! Just a couple of quick things. I am getting this notice: Notice: Use of undefined constant ENT_HTML5 - assumed 'ENT_HTML5' in /Users/ajones/Sites/pwtest/site/modules/ProcessDiagnostics/ProcessDiagnostics.module on line 301 Also, I'd like to add my support to horst's suggestion of a batch table optimize button, because as it is, it just ends up being much quicker to fire up PHPMyAdmin to optimize all at once. EDIT: Sorry, looks like that notice is only there on < PHP 5.4 - my testing server is still only running 5.3, even though my live sites are 5.4 or 5.5

Thanks for this. Glad I installed it as I had permission issues and mixed collation throughout the database. I have no idea what I'm doing, but I changed them all to utf8_general_ci and I assume all is good as nothing has blown up, and the satellites are still orbiting the earth.

I just set up a textarea field, add the Textile formatter to it, and then use the appropriate code such as bc.. which is short for block code. bc.. INPUT "What is your name: ", UserName$ PRINT "Hello "; UserName$ DO INPUT "How many stars do you want: ", NumStars Stars$ = STRING$(NumStars, "*") PRINT Stars$ For more info have a look here. Hope that helps?

I would prefer the solution Marc suggested: made a stable and development lang-pack. If we made a 'one-for-all' there will be a lot of abandoned and doubled strings. The updates of the dev PW often change the strings inside. So I think making and maintain two versions of lang-packs is easier. When a new PW stable version is published, we can rename the dev-lang to e.g. version 2.5 and so on. And start the next dev-lang from 2.5.

$var = (int) NULL; Will result in zero, unless there is some weird PHP setup I'm not aware of.

Include dazzyweb in there. C'mon England! Did Italy really draw 1 - 1 to Luxembourg a few days ago?

Thanks for the info Soma, Better documentation would be handy, but it's an awful lot of work to do & maybe even more to maintain it all. We all know Ryan works his but off. The amount of work he does isn't possible but he's doing even more than that What I think is possible is a set of really well written boilerplates for modules like the ProcessHello.module (Wonderful starting point). I would love to see a boilerplate for fieldtype & inputfield. The exchange of data information those two needs is still a little vague for me. Often the data you need is not net there. All in all I do think we are in a very luxury position, as documentation in general ( API level ) is very comprehensive.

If you are comfortable with PHP, with PW you can have your cake and eat it too! I realize I didn't clarify what I meant by the 'basics'...apart from PHP, that's also mainly the 'simple' but powerful PW basic API that is documented here: http://processwire.com/api/ especially selectors, $page and $pages. If you get those under your belt you will be truly on your way. As usual, feel free to ask questions and we'll be here to guide you....

....I was coming to that...OK, let's not kid ourselves, England is not going to win the WC. But, I think our boys will do well this time because there is less fuss this time round around the whole English team, less circus, etc. There's really no expectation on our part. I think the young lads will do us proud nevertheless...they have no past baggage so to speak, are really good players and have nothing to lose. C'mon England!

I've been working hard on this module this week, and so far, so good - it's now recording and can repeat most changes to Fields, Templates and Fieldgroups. One remaining issue is foreign keys... some field types store Template IDs, Page IDs or other types of ID within the Field data. For the known field types such as PageReference, I can handle those cases explicitly, but for third-party types, there is no saying what they're storing, where, how or when. The only real solution I can think of is some kind of hook that permits other modules to support this module explicitly, by implementing methods that clean up foreign keys and replace them with names, and vice-versa... but that's not really elegant and the module won't work generally with every third-party field type out of the box. Any thoughts?

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.

Kongondo, Which part of the UK are you from? I noticed you didn't mention England.

Finland for the win! Litmanen is the king!

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*

If someone want's to use this as kind of an intro or want to play around with it just drop me a line and I'll send you the after effects file or rendered 1080p version of it. If you need another background just give me the image and I'll create a video or you. I think that would be a great addition for the screencasts we recently talked about.

The point is, what country would pwired choose !

Umm.. probably a stupid question, but in your picture ProcessWire startup time looks more like 0.6ms than 600ms. Which doesn't seem that bad. Am I reading this wrong?

Yes, Brazil didn't play well! Wow; that's a lot of people. Interesting game that one (Spain vs Netherlands) but am sorry, I think Spain will win

This is really rough, but I have tested it and it does work $p = $pages->get("/test/"); $rf = "repeater_test"; //repeater field name $ptf = "pagetabletest"; //pagetable field name $ptt = "basic-page"; //pagetable template name foreach($p->$rf as $r){ $npt = new Page(); $npt->of(false); $npt->template = $ptt; $npt->parent = $p; foreach($r->fields as $f){ $npt->$f = $r->$f; } $npt->save(); $p->of(false); $p->$ptf->add($npt); $p->save(); } The key thing is that for this to work as is, the repeater field must include a title field, because this is used to generate the names of the child pages for the pagetable entries. You could of course manually add a title field in the loop when creating the $npt page. EDIT: You can ignore the need for a title by making the title hidden and not required in the context of the pagetable template and setting a value for the automatic page name format when setting up the pagetable field. For this to work, the pagetable field must be already set up and ready to go. If I had more time today, I would have enhanced this a little more regarding the title/name issue, but hopefully it should get you going.

Since ProcessWire and its modules/plugins do not output any HTML by itself, you are completely free in how you wrap the data from the pages. This gives you as developer complete freedom how you present the data. You could use HTML, XML, or even just JSON. This is the reason why there are no themes for the front-end availabe.

It doesn't have a theme system - but that means you can style it without any restrictions whatsoever. Stylewise, the better your HTML, CSS skills are, the better PW "theming" outcome is.

Hi Mosravo, Welcome to PW! That's right. You can use any HTML, whatever, you like with ProcessWire and style it as you wish. The Site Profiles you talk about are sort of something of convenience, ready made for those who wish to use them. And even then, once you've installed them you can bend them left right or centre as you wish. In other words, there are no ProcessWire themes..

Hi mosravo, different to Wordpress and others, ProcessWire has no "theme as a package" logic. Its philosophy is to provide a content framework and an easy API, where a clean WordPress install confronts you both with a certain content logic (pages vs. articles) and a certain theme installed (and the call to action to download/try more themes). So, if you discover certain projects and sites being realized with PW, the chance of this being a theme (as in: free download provided somewhere) is close to zero. But still, these projects can serve as a showcase for what's possible with PW. Maybe lets compare it to a (fictional) lego product: one is already assembled on purchase and has 3 or 4 big chunks of lego bricks (and you still could go to nearly every single brick if you want to) - that would be WordPress. ProcessWire is more of a box of bricks of every possible form, preassembled if you want to ( = site profiles) but foremost provided with plans of possible outcomes ( = this forum, and the docs). But still, you have to "now your lego" to at least a small extent minimum.

I made a video too: (it's converting currently)

@pleini Since you can create whatever fields you want you can also create whatever variants you want. On your template (not template file) you might want to have different tabs for different devices. However, since you want to have exactly the same data in all devices (wise choice), there is no need. You can do this as part of your template file, which is far more useful. Then the user does not have to worry about devices, the template files will sort that out. You can also use bits of php - so, for instance, you might want to break an article up into a series of iPhone sized swipeable pages, but just for phones. So, you use a bit of php to break your text up into the right sized junks and then use some sort of content slider to display them. On a Desktop, it would just show as one page. But this is all work you can do in your template files while leaving your templates/fields uncomplicated. I don't think Bootstrap has the equivilent of interchange, but I am sure there are plenty of jquery plugins out there that you could use. like response.js http://responsejs.com/

Thanks, Gayan - much appreciated.

Matthew found it and then told me he would break both my legs if I did not abandon Joomla at once and start using it.

PawelGIX, just to let you know I forked your repo in Github and added the functionality to handle edit cropimage thumbnails. The 'Edit in Pixlr Editor' function appeared to be broken in the latest PW so I added a fix for that too

Hi, im making a website with alot of articles, my structure looks like this NEWS CATEGORY article item CATEGORY article item CATEGORY article item CATEGORY article item CATEGORY On home page im listing all articles from all categories - 25 articles per page. Im opening them in Fancybox Insite article i have next and previous buttons, on click im loading content of article via ajax, replacing content in fancybox. and i change history via history api for seo reasons. My question is: Is there a way to make next and prev buttons change thru articles but listed on my home page (included next pages) instead of picking next or prev from category the article is nested in ? Would be grateful for some tips on that. Cheers

tells user.restart browser ? try disable csrf if no fix /site/config.php u try $config->protectCSRF=false; gazley dark, beard.looking good keep working.at it too

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.