Leaderboard

@doolak: It is important to realize that the JSON-data returned by the module will be decoded into a "dummy" PHP object (an instance of stdClass), based purely on the raw information that can be seen in the JSON-representation. Such an object has nothing to do with ProcessWire's objects/classes. So the consuming service has absolutely no idea of any other properties other than those that are given to it by the module. You can basically compare it to an array. Hence you cannot use any properties related to a ProcessWire class, such as FieldtypeImage. The simplest option is to build the URL manually, e.g. <img src="http://xyz.de/site/assets/<?php echo ($post->id . '/' . $post->mf_termin_image->basename); ?>">

Hey Pete! Altering the underlying column from a FLOAT to DECIMAL is safe - the other way around not so much, especially with high precision deicmals. It would also be quite trivial to implement a conversion UI directly in the module (i.e. so that the module lists FieldtypeFloats and lets you select which fields to convert into FieldtypeDecimal). Let me know if this feature would help your case - I'm back in the game so, once again, I have time to contribute to this lovely community

guess i'm the someone else.. after just having built several blogs with PW, i do wonder why anyone would willingly use that awful WP interface, and the annoying media manager, not to mention things like featured image etc.. i guess for power bloggers, WP probably has some advantages, but most of my clients just need a simple blog that they can edit quickly and easily..

@thetuningspoon: There is only one way to extend the Page -class, e.g. <?php class MyPage extends Page { public function myFunction() { return "I have been created for great endeavours" } } ?> After you have made sure the class exists (preferrably through autoloading), you just enter the name of the class into the 'System' -tab of the template in question (under "Page Class Name").

Hi Peter, When I first looked at PW, the docs were referring to templates. I admit that my first impression was based on cursory observations. After looking at CMSs and framework applications for two weeks straight, I assumed that PW was the same as the rest, and dismissed it as such. I had basically resolved myself to writing my own CMF (not CMS) to complete some upcoming projects. The version I looked at was current two weeks ago (I don't recall the version number). I have since been running the dev version. I am still trying to recall the issue I was researching when I came across a solution that mentioned PW. At that time, I looked more in-depth, and I am glad I came back and gave it a second chance. I really like the structure and how well engineered it is. Ryan has done an amazing job, and the support here is from highly skilled programmers as well. I have nowhere near the skill level they have, which is causing me some headaches trying to adjust to the page and template context of PW from what I have experienced in the past. That is not a deterrent, it simply means my learning curve is somewhat vertical.

The source is on GitHub, knock yourself out https://github.com/mindplay-dk/SystemMigrations

You can actually select repeater pages by their template: $pages->find("template=repeater_fieldName");

Hi! Just finished my first module This module adds a new "Google-Analytics" Page in your Admin-Panel and displays various Statistics from a Google Analytics Account. It uses the JQuery plugin "jqplot" to display the charts. Github: https://github.com/w...GoogleAnalytics Modules directory: http://modules.proce...ogle-analytics/ Features Visits by Date (Chart) General Statistics about Visits (Total visits, Visit duration, New visitors, Returning visitors etc.) Demographics: Countries, Cities, Languages System: Browsers, Operating Systems, Screen Resolutions Mobile: Operating Systems, Screen Resolutions Pageviews by Date (Chart) Top Content Traffic Sources: Keywords, Referral Traffic by Domain and URI Choose a default date range displaying statistics: last 24 hours, 2 days, 1 week, 1 month etc. Custom date range by setting a "start date" and "end date" Requirements Google Account and Analytics Account A Project in the Google APIs Console cURL Installation 1) Create a Project in the Google APIs Console: Create a new Project in the APIs Console: code.google.com/apis/console/ Under Services, enable the Analytics API Under API Access: create an Oauth 2.0 Client-ID Give a Product Name, choose "Web-Application", Domain doesn't matter Enter a Redirect URI to the GA-Page in your Processwire Installation: http://yourdomain.com/processwire/google-analytics/ Notes: The redirect URI must exactly match with the URL from the new "Google Analytics" page in Processwire. Open the Page and copy the URL from the address-bar (localhost does work too!) The project created in the APIs Console can be reused for every Processwire installation using this module. You just have to enter more redirect URIs 2) Install the module: Place the module's files in /site/modules/ProcessGoogleAnalytics Install the Module via the Admin-Panel Enter Client-ID and Client-Secret keys from the created project in the module config Load the newly created page "Google-Analytics" and click on the button "authenticate" Grant the module access to the Analytics Data Choose a Google Analytics account (Domain) from the dropdown Done: You should see the statistics. Check out the module config options for further customization In order to let other users see the Google Analytics page, you must give their role access to the "ga-view" permission. Ps. Processwire is awesome and so is this community!

: Guys, this is sooooo cool !!! Having seen the modifications done to the bike, and checked with google, this is not fake, but for real !! Discharge from coding for 4 minutes and enjoy watching this => It actually starts at 1:12 .

Would anyone else like to see the ability to make use of PW variables to build up dynamic descriptions and notes for fields? This is a very simplistic example and not that useful, but I do have some use cases where the ability to do something like this would be very handy: $f->description = __('Please make sure you fill out this field based on the content of the {page.parent.title} summary field.'); As I said - a bad example, but I think this could be a powerful addition in some scenarios.

Hi Forum, I recently had a chat with a friend who was introduced to PW by me. He said: "brilliant cms, poor documentation." His comment makes me think about the cheatsheet: While we see new API methods introduced at a very fast pace, the cheatsheet doesn't seem to keep up. That's sad, because it's such a good resource. So, how can I (as a user with very limited PHP skills) help to update the cheatsheet? Is somebody skilled willing to team up with me - as kind of a supervisor - for the update tasks? Or are there any plans on behalf of the team to update the cheatsheet? Thanks!

Hey guys, this may be interesting to join http://alistapart.com/blog/post/cms-event August 25, via Google Hangouts. Of course they will try to sell Craft and EE, as usual, but might still be good.

Hello all! I'm not sure if this is the correct forum to post an introduction, but I didn't want to clutter a specific topic elsewhere. I've been reading various forum topics, wiki, and docs, for the past twenty or so hours and decided to sign up last night. I just want to say that I am impressed with Processwire itself, as well as the community's eagerness to assist us newbies. I'll most likely have a number of questions later. As of now, I suffer from information overload due to the amount of reasearch over the past few weeks. I'm sure some of you old-timers, like myself, are familiar with *Tilt*, which is currently emblazoned on the back of my eyeballs. I look forward to learning and working with PW on a number of up-coming projects, and eventually become a contributing member of this community. Thanks for having me. Best regards, Rick

Hi everyone, I'm starting to code PW side of my first ever PW project. Really excited to see how it goes. While starting out I'm planning a template approach to use in the project mostly relying on wireRenderFile method. As it is my first project I wanted to make sure this won't cause me problems in the long run. Here is how I started out: I have two functions in _func.php as helpers. One of them is wrapper for wireRenderFile and the other is appender for $content for not using $content .= everywhere I have a global variable called $site. I normally avoid global variables but in this case I'll only have one and its not so different than using $homepage or $title before the includes (or is it??). I'm thinking about making a module for this to keep _init.php clean And in the _main.php my code is like that, with the common areas for pages. For the content of pages, I echo $content for the page content I gathered. For example, for basic-page template file: You can see usage of both functions here. That's all for the start. I'm trying to keep it simple to prevent going out of my hand. Do you see any "do not" or "should not" points here, or have any kind of recommendations? Thanks ahead

Well your thoughts were right on the spot. It's better to be safe than sorry, right? You can easily completely corrupt your data when modifying existing columns in the database.

I'm going to skip the question "why" and leave that for someone else as I'm guessing there's a good reason for using Wordpress for the blog portion or you wouldn't be doing it this way The way you could do this, without having to try and bootstrap ProcessWire with every Wordpress page load, is to use a caching method as you said. MarkupCache should be able to handle this I think: https://processwire.com/talk/topic/7-new-markupcache-module/ You would have to store all the header data in a varialble and save it to the cache (as per the examples in that topic), but it would have been parsed correctly by ProcessWire and would be standard HTML in the cache and therefore ready to use elsewhere. Same again for the footer. Then you should (theoretically) be able to just include those cache files into your Wordpress template files and hey presto! It would be worth testing with a small bit of text in a MarkupCache cache file and seeing if that works.

Haha here's the quickie then ALTER TABLE `field_<the_name_of_the_float_field>` MODIFY data DECIMAL(12,2); UPDATE fields SET type='FieldtypeDecimal' WHERE id=<the_id_of_the_float_field>; If you need more than two decimals (or more than twelve digits in general), you can safely increase the precision through the module afterwards.

Welcome to the forums rick

Welcome Back !

@adrian - this is to confirm that now it works as expected. Thank you for this module!

You can check this by enabling "view system templates" in the template overview. This should show those automatically created templates. Edit: you need to literally add "repeater_" in front of thr name.

Some time ago we did a redesign and relaunch of http://www.pipistrello.ch/ using ProcessWire. A Circus for children to participate. The design and html theme is wanted and bought by the client, so we don't take credits for that other than ProcessWire work and some small adjustments as was requested.

Solved after adding slash after domain name, or maybe was a question of time from google to update. Thank you.

Hi Manol, You have to enter the redirect URL in the Google API console. Google needs to know the URL of the app. Cheers

What is of() Baby don't hurt me Don't hurt me no more can't stop singing

It is an alias for setOutputFormatting and it is directly under this one on cheatsheet http://cheatsheet.processwire.com/?filter=$page-%3Eof(true|false)

@adrian, ups, yes this is directed to you.) Replaced, but it does not fix a problem.( Particular setup: - module is installed with checked Hide "children, settings, delete" in settings - there is user X with role "content-editor". - when role "content-editor" has only "tab-settings-hide" and "tab-delete-hide" permissions - everything is OK, e.g. no any tabs in the page (btw children tab is also hidden) - when role "content-editor" has also "tab-children-hide" permission => error above Again, this happened in PW 2.6.10 dev - could be either result of permission system changes or simply dev bugs... Anyway, looks like this code may not setup $fieldset in some cases: if($tab == "Settings" || $tab == "Children") { $fieldset = $form->find("id=ProcessPageEdit".$tab)->first(); } else { $fieldset = $form->find("id=ProcessPageEdit".$tab); } P.S. The same error is thrown in another scenario - when editing "user" page by different user/role. But now issue is with "tab-settings-hide" only... P.S. Just idea - may be some tabs in some cases can't be found with $form->find? E.g. for example when user does not have access to add children (restricted at template level) then Children tab is not displayed. EDIT: Temporarily made quickfix after if-else block above: if (!is_object($fieldset)) return; It prevents errors - module works as expected at all pages. Except "user" page - here "delete" tab does not disappear (while "tab-delete-hide is ON"), but "children" tab disappears ("tab-children-hide" is ON too).

Maybe you need to set "include=hidden".

Thanks for all your responses, I was able to find a solution with mysql in the meantime. I figured out that language fields have all the same name in the database : data1013 -> 'fr', data1017 -> 'be' in my case. To find every table that have language fields i used this query : SELECT DISTINCT TABLE_NAME as mytable FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME IN ('data1013') AND TABLE_SCHEMA='processwire'; and on every table found i applied this query to duplicate the fields : UPDATE <table_name> SET data1017 = data1013; And of course i made a backup of my database before i made any update query

You haven't done your homework

They are pages. Look for them under "Repeaters" inside the admin page in the tree. Repeater pages are under a page with the name "for-page-1234" (1234 is the ID of the page that holds the repeater field) under a page named "for-field-123" (being 123 the id of the repeater field. You can see it o the URL when editing the field). This means that you can easily get all pages from a repeater field in a page by using the selector: $pages->find("parent=/processwire/repeaters/for-field-123/for-page-1234") Or even construct that selector dynamically when needed: $pages->find("parent=/processwire/repeaters/for-field-130/for-page-{$page->id}")

Hi, I've published Version 0.4.1 of Abbreviate. The following changes are included. fixed #1 possible value overwriting with empty strings Better auto mark up fixed #1 possible value overwriting with empty strings It is no longer allowed to set a empty String on the language attribute if there is a value set. This fixes bug #1 in the issue tracker. For the same behavior I've edited the code line also for the abbreviation text. Better auto mark up I've removed the right word boundary check, because german abbreviation style like z.B. or usw. couldn't found automatically cause the dot character is a non word character. Is there any developer with regex knowledge you can support me in creating a better regex for the auto mark up feature? Currently it feels a little bit rudimentary and not finished yet. I use this feature by myself and it works in most cases, but I think there are certain edge cases. The new version is pushed to GitHub and will be available soon via the system updater. regards, Sven

Julia, can you tell us about your experience with PW on that host? I removed the link from your answer, you're too young to link.

Even the core does use links in notes, especially for the more documentation-needing features like for example the urlSegment whitelisting. So there needed to be a way to create those.

You can link by using markdown [my-link](http://processwire.com). But be aware, it's not a full-blown markdown parser, which does this job, so other syntax might or might not work. About the overhead. Ryan did mention somewhere, when someone asked about better markdown support, that that would be a performance hit, so I'm not sure if it's wise to back notes/descriptions with features. It's really one of those "called everywhere and often" things.

sometimes i wished the descriptions support html for linking to something. if it supported html+php we could combine both: eg ...based on the content of <a href="<?php echo $page->parent->url; ?>"><?php echo $page->parent->title; ?></a>'s summary field... but i have absolutely no idea how much effort/overhead that would be

It is interesting that you say that. What I like about ProcessWire is what I like about my choice in OS. This opinion is based solely on my developer-centric view, and not from the view of my clients. ProcessWire to me is akin to the *NIX of operating systems. Other so called CMSs, especially the more popular ones (wordpress, drupal, et al.), are the windows wrapper versions, whereas the MVCs (and Smartys/Twigs impementations) are the mutated CP/Ms. Everyone believes they have a better mouse-trap. And Yes. You can use their self-proclaimed turbo-charged, lemon-fresh, automatic-transmission mouse trap to kill a mouse, but at exorbitant cost for the supporting systems and learning curves of the end-user. ProcessWire is well architected, particularly so for us 'geeks', as is Unix. And that is where the trumpeted "User Friendly" rears it's ugly head. I'm not knocking the opinion of others. This is, after all, only my opinion. I don't mind so much the Gnome [x-windows, etc.] attempts to make *nix more user-friendly, but please, please, don't bastardize ProcessWire into Windows98.

I don't consider myself an advanced programmer, neither am I a beginner. As I said in <a href="https://processwire.com/talk/topic/2311-processwire-on-the-web/page-17#entry99587">this</a> post, I balked at PW at first. The first articles I read referred to 'templates'. I wasn't looking for another app with a template engine, so I passed on digging deeper, and continued on with my search. It was the term 'template' that initially turned me away. After looking at all the cms and framework files, I thought, "Great, another idea for a better mouse trap. ...Again." Each and every one of those cms and framewoork apps do not come anywhere close to processwire. Don't get me wrong, I've been using many of them for years, and I am not putting them down. They serve a purpose -- Just not my purpose. From what I have been reading on this forum over the past few days, there is a great group ready and willing to help, and the development is heading in a direction that will support us newer members becoming a more integral part in the future. I don't see PW living between casual and advanced users at all. I see PW as it being what you need it to be. If you need casual, it fits. If you need advanced, it fits. </ .02

Hey, a lot of times I create a role called "editor" and give all of the page-* permissions to it. No problems so far. But I normally forget to go to "home" template afterwards to set the permissions for the template, too. So my idea is to show a list of templates (maybe only the once you have selected as "Manage access individually") in a list like the following in the role edit screen: I think this would be a huge performance improvement and could save a lot of confusion and clicks.

Ivan, the input pattern is part of the input module (InputfieldText), and performed as part of the input validation. When assigning values from the API side, it is not considered user submitted input, so the Inputfield is not involved, and likewise the pattern is not a factor. When editing a field, you'll see "Details" and "Input" tab. All the settings on the Details tab are specific to the Fieldtype in use, whereas all settings on the Input tab are specific to the Inputfield. While we could move a setting like that to the Fieldtype, it's not ideal because plenty of other Inputfields extend InputfieldText, and are able to likewise benefit from the pattern support that it provides. Further, Fieldtypes are most efficient when they only perform very quick validations (like validation for type) since the Fieldtype's validation/sanitization occurs every time a value is populated to the page from the API (like every time a page is loaded), and validating a regex pattern is a relatively slow process.

Hi, I've been developing a lot of portfolio websites lately, mostly for freelancers and small companies, and talking to a fellow developer the other day, I realized that he's consistently quoting more hours than me for essentially the same kind of job. At first I thought, nah, he's clearly overcharging his clients but after giving it some more thought, it ocurred to me that maybe I'm the one who is undercharging! So, here's the type of project I'm talking about: - 5-page website (home, about, services, pricing, contact) - Custom design: sometimes I come up with the design myself and sometimes I adapt a Bootstrap/some other framework theme - Responsive design (of course!) - Not much custom programming going on, mostly a very basic contact form on some of the websites - Sometimes I code these sites with ProcessWire and sometimes I make them static, depending on the client's budget - The sites are mostly informative in nature, so they don't require any fancy JavaScript or anything like that. They also don't require login pages for clients or anything like that. Here's what my friend and I would quote for such a project: I quote: Static 5-page site: 16-24 hours Processwire 5-page site: 30-40 hours My friend quotes: Static 5-page site: 40-65 hours Processwire 5-page site: 60 hours Now, I'm really curious at to the number of hours you would quote for a project similar to the one above, both for a Processwire and a static site. Thanks for sharing!

http://blog.jquery.com/2015/07/13/jquery-3-0-and-jquery-compat-3-0-alpha-versions-released/ Please check your code for how you use the .show() and .hide() methods! I did a quick grep for a 2.6.9 site (has a dozen random modules) and the .js files listed below were using .show(). It might well be that some of them will break with jQuery 3.0. BatchChildEditor.js ProcessBatcher.js AdminThemeReno\scripts\main.js InputfieldFile.js InputfieldPageAutocomplete.js InputfieldSelector.js JqueryTableSorter\widgets.js JqueryWireTabs.js ProcessField.js ProcessModule.js ProcessPageAdd.js ProcessPageEditImageSelect.js ProcessPageEditLink.js ProcessPageList.js ProcessPageLister.js ProcessPageSearch.js ProcessTemplate.js SystemNotifications\Notifications.js templates-admin\scripts\inputfields.js templates-admin\scripts\main.js

Quick overview of some updates I'll be sending to Ryan tomorrow. New Features: Sidebar saves open/closed state. Sidebar opens/closes with arrow keys. Sidebar toggle icon moved. Search input is now a masthead overlay. It's takes the same number of clicks as before (one) since the input is focused on click. The overlay can be closed with the (x) icon, or the up arrow key. User information is now customizable to any text fields associated with the user template. So you can use fields like a first_name last_name. Custom color schemes can be set in /site/modules/AdminTheme/AdminThemeReno/styles/. These files survive PW updates, so you can easily create custom variations on the theme without having to reinstall it after an update. (Thanks Pete!) Top navigation items are now hookable, so you can add additional single or nested items. Top navigation has quicklinks to ProcessWire resources for Superusers. (forums, docs, github, cheat sheet, etc..) There are other tweaks and fixes here and there, but these are all I can think of right now... Changes to masthead and top navigation Superuser Quicklinks User Information Search Overlay

I have brought this up with Ryan already, so hopefully it is on his radar. Perhaps an issue on Github would be a good reminder for him though. This was my message to him:

When I started working on my first ProcessWire site I liked that by simply opening the basic-page.php template file (obviously connected to basic-page template), I could instantly see how everything worked. It was easy to start from there, building more complexity and adding those "advanced tricks" if/when needed. Things like delayed output, appendTemplateFile/prependTemplateFile, etc. raise the bar of entry, that's just how it works. They're things you won't simply "get on the first sight". You'll have to dig through other template, config and README files (or docs) to understand what's going on. However you look at it, things that "just magically do something" may be helpful and ease your workload once you understand how they work, but also tend to add to the frustration a new user feels getting used to the system. Personally I believe that the "first dive" into a new system should be as easy and enjoyable as possible. Anything that complicates things is likely to increase the bounce rate.

Here's an example module that removes "Add New" button(s) on InputfieldPageTable on a condition (here if there's 2 ore more entries). Hook before InputfieldPageTable::render, then add hook after InputfieldButton::render. Since InputfieldButton is used by PageTable, we just use that hook to empty the returned markup for the button. Then remove that button hook after the InputfieldPageTable rendered. https://gist.github.com/somatonic/c9db5c43f10d050bb14d

Relative time was introduced in 2.3: http://processwire.com/about/news/introducing-processwire-2.3/ Not sure about the differences as I've not checked out the other module. EDIT: Oooh he beat me to it by seconds

All the WP sites I did in the past (way too many of them, now I switched entirely to PW, I even redid whole clients simple "brochure" websites pro-bono to save me the hassle) have been ok, but there's always something with the API that doesn't work quite right (future dates in queries, good luck!), maintenance issues, compatibility issues (loading 10 versions of jquery and the like). Some things might work right when developping, but often I need to change the plugins code to improve them, which is a problem. Then when new versions of everything comes out, it's a mess. WP sites don't seem to grow very well either, so as complexity increases, it all falls apart. Speed issues are also a big thing and really hard to optimize to get good load times. All that time waiting for the admin to do stuff is wasted time in billable hours (I charge a minimum of 30 mins for maintenance, most things take less than 15 mins to do, the process is usually much faster in PW I've found so far). Also take into account that when you do full-custom work like I do (I'm a designer AND a programmer), WP always comes with either too many or not enough features. That's time I need to just do configuration to get rid of the unneeded parts, which sometimes isn't really straightforward. I also do a lot of multilingual things, WP can do it with plugins, but the workflow is kinda weird and involves a lot of support calls from clients. Some of the features don't work so well either. So far what I've launched with PW is trouble free. It does everything much better and faster. I can say with big relief that WP's custom post types are a thing of the past. I was able to implement different relatively "complex" things (well, would be in WP) like 100% custom event systems, payment/donation systems, etc (hopefully will be able to package some of them nicely to reuse later and share in modules) in next to no time. Now I'm happier, clients are happier, work is faster, everybody wins.

Type in your home template or else. $u = $users->get('admin'); $u->of(false); $u->pass = 'superSecretPassword'; $u->save(); Then go to a page with that template. Then go to /processwire/ & login. --- I almost forgot: Welcome Bosse1981 !

Pattern support is now in place for text fields (dev branch). The pattern applies both client side (HTML5 pattern attribute) and server side, for the validation. I looked through all of those patterns are html5pattern.com and couldn't find any that weren't PCRE compatible. So if it's not 100% compatible, I sure can't tell the difference. My guess is that HTML5 patterns are compatible with PCRE, but some of the more advanced PCRE stuff (maybe atomic grouping or negative lookbehind?) might not be compatible with HTML5.