Leaderboard

Guys hope you don't mind but this thread is entirely too bizarre, so I'm closing it. There's some good stuff here too, so not going to delete it, but please continue your conversation in a new thread if you want to– just no more name calling, PW death threats or summoning gods. Or if you must, then keep that stuff in the Pub. The general support is not the place for this. -- Edit: just moved this to Pub.

Three days at Beyond Tellerand made @marcus and me spawn some great ideas for this. One of which is that we will maintain a text-based repo of recipes, so that they are decoupled of any database, are properly version controlled and anyone with a GitHub account can contribute easily. This may be great opportunity for those of you who have not yet been using something like git to finally dive into it. I wrote an importer module, which already works pretty well. The rough structure is decided upon as well. Let's get it on! PS: we also met nico one day, what a very nice fella he is .. I had too much to drink that night though

No. Have a read here: https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/. Create one such field and change its label in the context of those templates.

Basically, yeah. As an example, (part of) a fictional site tree: items -item(newsitem) -item(pressrelease) -item(statusupdate) -item(newsitem) -item(newsitem) -item(pressrelease) tools -item_categories --newsitem --statusupdate --pressrelease My item template would have a page field referencing 'item_categories' as the parent for my item categories. This way, when you make a new item you choose the category which it belongs to. Very flexible, and using selectors you can then use your items to display however and wherever you want in your site. Make an RSS feed of your press releases? easy. And, because it's all pages, infinitely scalable. For easy back-end management you could set up a couple listers, if you want to. EDIT: the tools section would usually be a hidden section, a building block section if you will.

I would make it scalable from the outset. I have had exactly the same issue, though I have approached it for different reasons - SEO. In this case, each product can have a different material or different base. It suddenly struck me that people might want to look through the cataglogue from a differetn angle - look at the materials, see what the differences are and then list the products that are made with that material. That meant those materials needed to be pages. Page table might be the way to go. There is a module called page table extended that improves layout, by the way, but it has problems with the current dev - the lovely chappy is working on it, though

There's is now a translation tool in core that will find all translatable files automatically. Just click and add.

Have you not heard of a contract or an NDA before? I explained what I'd done and furthermore posted that you are only limited by your imagination. The latter means no examples are really necessary - you can do what you like in ProcessWire - if you can imagine it you can build it. I cannot show you what I have done on that intranet and nor am I going to spend many unpaid hours anonymising it to show you mocked-up data that doesn't mean much out of context in some of those areas - you will have to take my word for it that I built those things As much as I would love to share a video, I cannot and I suspect there are plenty of others here in the same boat who have a lot of paid work on and can only share what they are allowed to when time permits. Take our word for it though - you can build what you like. More examples will come with time, but I don't think a shortage of examples is preventing people from using the system - it's more likely a shortage of free time. What little I see of other systems suggests a younger userbase where they have more time, though I may be wrong - anyway, our productivity will only increase as the community grows. Also, please don't swear and expect any sort of civil replies - I think you're getting confused about what people are talking about with maintainablility. To my mind, the huge cohesive modular system you are talking about doesn't touch the core - you're right there - but would be a mammoth task to build and maintain. It is scary - don't play that part down please. I have built a handful of modules and struggle to answer issues on GitHub - scale that up by a factor of a hundred (or more) and you can see where the problem is. Also, as someone already said, ecommerce in its more comlpex form (product variations etc) as in Magento and even lighter-weight scripts is months/years of work so there is a huge amount of work involved in what you have listed that then needs to be maintained - not just the ecommerce bit. None of that is meant to suggest it won't happen eventually - I'm sure it will, but it's not going to happen instantly and only productive discussion will make it happen, not frustration (from any side of the fence, if indeed there really is a fence). The ProcessWire API is abstracted as it is solely for usability and to prevent things breaking, so no worries there. I shudder to think about a system where the core devs would change things purely to break someone else's work and I very much doubt (though I've not read nor do I have the time to at 3.30am) a core dev team would do that on purpose unless they were refactoring their core code for good reason (PHP versions march on and there are benefits to be had from changing code). With ProcessWire though, ryan could completely rewrite the whole thing from the ground up and as long as the API calls were the same it wouldn't matter - that's the beauty of it - you don't have to worry about what the core module code looks like behind the scenes or about your modules breaking over time EDIT: Sorry, I am able to reply to closed topics and I wasn't aware this was closed before I posted and it's very early in the AM here so that wasn't intentional to get the last word in.

A little more civility, respect of others beliefs and an actual ability work in a collaborative environment would make these discussions productive.

hi zeka, welcome to processwire i switched from seblod to pw some months ago and i hope you will enjoy your move as much as i do! you will be impressed by the great community and the fast and knowledgeable answers you will get here, i'm sure (knowing the pain with seblods forum support...). to your question... coming from joomla/seblod you have to change your mindset a little bit, i hope that i can help you with some comparisons: articles/items (joomla/seblod) = pages (pw) in pw everything is a page! thats very important to understand. pages can store any data you want. it's like in seblod everything is stored in joomla articles, pw stores everything in pages. pages can have completely individual set of data-fields (eg. headline, body, images, starttime, endtime etc.). this setting of fields is defined by "templates": content types (seblod) = templates (pw) in your templates you define which fields will be available in your page. some examples: template "blog-post.php" # field "title" # field "body" # field "author" template "product.php" # field "title" # field "description" # field "price" # field "image" so if you created a new page "product" you would only have the fields "title, desc, price, image" available for editing. list&search (seblod) = selectors (pw) forget list&search types!! selectors are the way to go with pw say we want to display some products with template "product" from above: $products = $pages->find("template=product, price>100, sort=price"); foreach($products as $item) { echo "<a href=\"$item->url\">$item->title</a><br>"; } see here for a quick glance: http://processwire.com/api/selectors/ (yes, everything is very well DOCUMENTED - that's another huge difference to seblod ) don't try to bring editing features to the frontend unless it is REALLY necessary joomla has a very complex backend, so i tried to hide this complexity for my clients by giving them edit access only for some parts of their website from frontend. processwire's backend is so simple that you will not need to hide it from your client anyway: if you have some experience in seblod, i think you will learn pw really fast and enjoy how clear and simple everything can be and now put everything together: https://processwire.com/talk/topic/693-small-project-walkthrough-planets/ if you have no dev-environment you can instantly setup a fresh copy of processwire here for free: https://lightning.pw/ have fun with processwire

FieldtypePageWithDate & InputfieldPageWithDate Module for ProcessWire - Page Reference with Date Field - Field that stores one or more references to ProcessWire pages Modified version of the FieldtypePage module in ProcessWire with extra datetime field containing the date a page was added to the inputfield. Github URL Link: FieldtypePageWithDate To install Copy to /site/modules/ and go to Admin > Modules > Check for new modules. Requirement Requires: InputfieldPageWithDate (will be installed automaticly) Tested on ProcessWire 2.5.6 dev Setup in back-end install both modules:FieldtypePageWithDate InputfieldPageWithDate create a new field in ProcessWire and give it a nameeg. myfriends as type choose PageWithDate choose the right dereference for your needs (all 3 modes work fine with this field)Multiple pages (PageArray) (in this example we are using this) Single page (Page) or boolean false when none selected Single page (Page) or empty page (NullPage) when none selected assign a selector to the field, in this example we will use users Template of selectable page(s) (select the user template) choose a label field, since we are using users set it to name Label Field name set an input field type, depending if you are using dereference of multiple or a single pagefor this example we are using AsmSelect save the field and assign it to a template of choice Add some users/friends to the field by editing a page with this template Usage in front-end In you template you can acces the field as you usualy do with any FieldtypePage. In addition to this the new parameter "assigned" is available Multiple pages if (count($page->myfriends)) { foreach($page->myfriends as $friend) { echo "id: ".$friend->id."<br>"; echo "name: ".$friend->name."<br>"; echo "assigned on: ".$friend->assigned."<br><br>"; } } This will output something like: id: 1031 name: johndoe assigned on: 2014-10-31 14:22:02 id: 1032 name: janedoe assigned on: 2013-04-15 23:16:38 Note: To use your own data/time formatting set $friend->of(false); to get a unix timestamp from the database Single page echo "id: ".$page->myfriends->id."<br>"; echo "name: ".$page->myfriends->name."<br>"; echo "assigned on: ".$page->myfriends->assigned."<br>";This will output something like: id: 1031 name: johndoe assigned on: 2014-10-31 14:22:02 Note: To use your own data/time formatting set $page->myfriends->of(false); to get a unix timestamp from the database Edited: removed extra date() formatting since value is formatted by default. Set assigned datetime manuallyYou can set datetime manually by assigning it to the page you add $friend = $users->get('johndoe'); $friend->assigned = "2012-01-01 12:12:12"; $page->myfriends->add($friend); $page->of(false); $page->save(); Edited: Added information on manually setting the assigned to a datetime value. (if you previously installed this module you need to update atleast the FieldtypePageWithDate.module file)

It's really easy with "Terminal" to get all the translatable files. Just open the root dir of your ProcessWire installation in the terminal ("cd /YOUR/DIR/PATH/" or drag'n'drop the folder onto the terminal.app icon). Then entering the following line: grep -lr '__(\|$this->_(' * grep search command -l only show filenames -r recursive '__(\|$this->_(' search term with OR ( \| ) condition * the folder you want to start the search in. because we are already in the folder because of "cd" we can use the asteric My result on PW 2.4.9: wire/core/AdminTheme.php wire/core/Field.php wire/core/Fields.php wire/core/FieldSelectorInfo.php wire/core/Fieldtype.php wire/core/FieldtypeMulti.php wire/core/Functions.php wire/core/Inputfield.php wire/core/InputfieldWrapper.php wire/core/LanguageFunctions.php wire/core/Modules.php wire/core/Pagefile.php wire/core/Pageimage.php wire/core/Pages.php wire/core/Password.php wire/core/Session.php wire/core/SessionCSRF.php wire/core/Wire.php wire/core/WireCache.php wire/core/WireHttp.php wire/core/WireUpload.php wire/modules/AdminTheme/AdminThemeDefault/AdminThemeDefault.module wire/modules/AdminTheme/AdminThemeDefault/AdminThemeDefaultHelpers.php wire/modules/AdminTheme/AdminThemeDefault/default.php wire/modules/Fieldtype/FieldtypeComments/CommentFilterAkismet.module wire/modules/Fieldtype/FieldtypeComments/CommentForm.php wire/modules/Fieldtype/FieldtypeComments/CommentList.php wire/modules/Fieldtype/FieldtypeComments/FieldtypeComments.module wire/modules/Fieldtype/FieldtypeComments/InputfieldCommentsAdmin.module wire/modules/Fieldtype/FieldtypeDatetime.module wire/modules/Fieldtype/FieldtypeFile.module wire/modules/Fieldtype/FieldtypeFloat.module wire/modules/Fieldtype/FieldtypeModule.module wire/modules/Fieldtype/FieldtypePage.module wire/modules/Fieldtype/FieldtypePageTable.module wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module wire/modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module wire/modules/Fieldtype/FieldtypeSelector.module wire/modules/Fieldtype/FieldtypeText.module wire/modules/Fieldtype/FieldtypeTextarea.module wire/modules/Fieldtype/FieldtypeURL.module wire/modules/Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.module wire/modules/Inputfield/InputfieldButton.module wire/modules/Inputfield/InputfieldCheckbox.module wire/modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.module wire/modules/Inputfield/InputfieldCKEditor/InputfieldCKEditor.module wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module wire/modules/Inputfield/InputfieldEmail.module wire/modules/Inputfield/InputfieldFieldset.module wire/modules/Inputfield/InputfieldFile/InputfieldFile.module wire/modules/Inputfield/InputfieldFloat.module wire/modules/Inputfield/InputfieldForm.module wire/modules/Inputfield/InputfieldHidden.module wire/modules/Inputfield/InputfieldImage/InputfieldImage.module wire/modules/Inputfield/InputfieldInteger.module wire/modules/Inputfield/InputfieldMarkup.module wire/modules/Inputfield/InputfieldName.module wire/modules/Inputfield/InputfieldPage/InputfieldPage.module wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTable.module wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTableAjax.php wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.module wire/modules/Inputfield/InputfieldPassword.module wire/modules/Inputfield/InputfieldRadios/InputfieldRadios.module wire/modules/Inputfield/InputfieldSelect.module wire/modules/Inputfield/InputfieldSelectMultiple.module wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module wire/modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module wire/modules/Inputfield/InputfieldText.module wire/modules/Inputfield/InputfieldTextarea.module wire/modules/Inputfield/InputfieldURL.module wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.module wire/modules/LanguageSupport/LanguageParser.php wire/modules/LanguageSupport/LanguageSupport.module wire/modules/LanguageSupport/LanguageSupportFields.module wire/modules/LanguageSupport/LanguageSupportPageNames.module wire/modules/LanguageSupport/LanguageTabs.module wire/modules/LanguageSupport/ProcessLanguage.module wire/modules/LanguageSupport/ProcessLanguageTranslator.module wire/modules/Markup/MarkupPageFields.module wire/modules/Markup/MarkupPagerNav/MarkupPagerNav.module wire/modules/PageRender.module wire/modules/Process/ProcessField/ProcessField.module wire/modules/Process/ProcessForgotPassword.module wire/modules/Process/ProcessHome.module wire/modules/Process/ProcessList.module wire/modules/Process/ProcessLogin/ProcessLogin.module wire/modules/Process/ProcessModule/ProcessModule.module wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module wire/modules/Process/ProcessPageClone.module wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module wire/modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module wire/modules/Process/ProcessPageEditLink/ProcessPageEditLink.module wire/modules/Process/ProcessPageList/ProcessPageList.module wire/modules/Process/ProcessPageLister/ProcessPageLister.module wire/modules/Process/ProcessPageSearch/ProcessPageSearch.module wire/modules/Process/ProcessPageSort.module wire/modules/Process/ProcessPageTrash.module wire/modules/Process/ProcessPageType/ProcessPageType.module wire/modules/Process/ProcessPageView.module wire/modules/Process/ProcessPermission/ProcessPermission.module wire/modules/Process/ProcessProfile/ProcessProfile.module wire/modules/Process/ProcessRole/ProcessRole.module wire/modules/Process/ProcessTemplate/ProcessTemplate.module wire/modules/Process/ProcessUser/ProcessUser.module wire/modules/Session/SessionHandlerDB/ProcessSessionDB.module wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module wire/modules/Session/SessionLoginThrottle/SessionLoginThrottle.module wire/modules/System/SystemUpdater/SystemUpdater.module wire/modules/Textformatter/TextformatterEntities.module wire/modules/Textformatter/TextformatterMarkdownExtra/markdown.php wire/templates-admin/debug.inc wire/templates-admin/default.php wire/templates-admin/topnav.inc (Inspired by Manfred62's post: https://processwire.com/talk/topic/7245-translation-for-pw-25/)

Would it be possible to add a Lister filter for text fields: "Does Not Contain"? I'm looking for the opposite of "Contains Text" shown below. We have "Not Equals", but no negative operator for partial string matches. Is this omitted because of performance concerns? Thanks!

Pootle had been mentioned earlier this year (see page 1).

If speed is not an issue, it might be something to do with easing that the iPad browser does not like very much. If you can change what sort of transition is happening and try a simpler one, that might give you a clue as to what is happening.

You can get there via the fields menu or directly from the template menu:

No! Fields can have different settings on a per template basis. This is called a context. A nice screenshot here: https://processwire.com/talk/topic/7274-are-there-better-fields-naming-convention/?p=70296

Let's face it, sometimes people just want to put their content out there and can't or don't want to pay for a good designer. I don't think everything has to be forcefully designed. Also, some designers don't do more than repeat the same system for all the websites, in the end 90% of the websites will look almost the same anyway. i really like the idea of an automated, competent, inexpensive system to create sites, in contrast to competent bespoke design. For now I don't know much about this tool and I wouldn't use it anyway because it's not aimed at professionals, but I'm still curious

@kixe: interesting! If you like, maybe just for testing you can make Notices::add (in wire/core/notices.php) hookable by preceding three underscores: ___add( And then there should be stored the last error / warning / message into class vars and if a comparision of a new arrived notice against that previous stored ones matches, one could simply drop them. Or something along that lines. If you work out a solution to make it better in the regard of double / multiple notices, you can post it to Ryan at Github.

Followed up the development of ProcessWire, the Hungarian language pack has been updated for PW 2.5.8. From PW 2.5.6 to PW 2.5.8, totally 10 translation files were updated, 1 new file was added. Translation changelogs for each release are available on the GitHub Project page. Download the full package via the ProcessWire Modules Directory: http://mods.pw/7h

Cheers Joss. You're right re. scalability. I was getting hung on "the simplicity" of the first approach (which uses PageTable). What I should be doing is making a simple template called "studio-update" with just my body field as date can be handled by the page creation date. Later on, I can add and remove fields if requirements grow. Or I could even have a Blog for this where posts for Updates are simply tagged "update". They could then be hidden from the main blog secton but displayed on their own "updates" page. Too much choice. That's my problem

Go to the guest user and change language to what you wish i.e. Deutsch. Having english as a second language is also easy, you don't need language translation files for english as it's already english, so just keep (core) it empty.

Yes, its not the biggest problem I have. But there should be a way to solve this. ProcessLogin.module (v101) gives an error notice if an index.php file from an older pw-version is found in the root directory. I played with this one too. I got 6 entries in errors.txt with the same message by one click. Two is ok, but six is too much for the best CMS in the world, isn't it?

I would like to recommend POOTLE http://pootle.translatehouse.org/?id=pootle/index Simply setup a subdomain http://translation.processwire.com install pootle here invite the complete community to help translating all files in the core and modules. It is a real community approach and it ensures high quality to. and it is very easy to handle! If you want to see how this looks like on a professional enterprise CMS than check it out here: http://translation.typo3.org/ add your own 2 letter language code and directly you get to your language. You can see immediately what translations are still needed. i.e. http://wiki.typo3.org/Translation#Using_Pootle here you can find a short tutorial and description on how to use Pootle. To make cooperation easier there is a Translation Terminology Project which ensures that things get named constantly the same way when building extensions. Standardization of the Translation you could call it! Setup a Team Page where you can inform about Teams and their members which do those translations or which actually manage also the access and ensure that translations get reviewed. http://wiki.typo3.org/Thai-Translation-Team We translated TYPO3 4.5 LTS 100% in 2010 but since than as you can see lots of words have already changed again in the core so we are working on the translation of TYPO3 6.2 LTS now. http://translation.typo3.org/th/ usually we do this with our Interns. It would be nice to see Processwire also in Thai Language. But translating it in the way you are doing it right now is a real hazzle and takes lots of time and does not at all allow collaboration. I think you could learn a lot from how TYPO3 is utilizing Pootle for all translations. Beside this the translations of Modules and core get loaded separately after installation. They also get updated from within TYPO3 which for sure would be also possible inside Processwire as you can update core and modules already why not also translations. As all translation files get stored on the translation server, the modules with their english default language file (some provide already some other languages from start) are kept free from not needed ballast. Best would beactually to make it a rule that all modules need to have the default in English like the core and that all other translations get stored and managed on Pootle. --- And it is getting even better with the upcoming release http://docs.translatehouse.org/projects/pootle/en/latest/developers/roadmap.html --- In General I would recommend to keep all language translations in a separate file. This usually also reduces hard coded stuff as developer get used to use translatable variables instead as also the default English Language would be in a separate file. site/module/abcdefgh/abcdefgh.module site/module/abcdefgh/locallang.xml site/l10n/de/abcdefgh/locallang.xlf site/l10n/de/abcdefgh/locallang.xml

@Nico yes you are right, otherwise it is nonsense. Pretty sure I will never use it ...

@steve: I don't see 'assigned' back in the names array of ->getMatchQuery, so I doubt. One thing I know for sure: Raymond will be open for enhancement.

Very nice! Perhaps some easing on the logo animation: .header__logo.header__logo--desktop {display: none;transition: all ease-in-out .3s;}

Love the theming! Huge points for a really sensitive choice of design colours and I love the gear theme. Also great little parallax library - I will check that out more.

@kixe: Maybe add check to prevent that this will be overwritten. $page->of(false); if($page->CustomFieldModified == '') $page->set('CustomFieldModified', $page->modified); if($page->CustomFieldCreated == '') $page->set('CustomFieldCreated', $page->created); $page->save();

@lisandi I wish I could give a like to some parts of your post and a dislike to other parts. I do like your enthusiasm and energy and honesty. You are not scared to share your opinions even if others don't agree and that can be a good thing even if it rocks the boat a bit. Hell I have done that a few times. I know that some of the answers here might seem a bit stick in the mud . I get it, really. I feel the same frustration sometimes but best to keep your posts civil. Everyone has their own ways of expression and perception and idea of where they would like Processwire to go. The guys and girls in this community are some of the best you will find. We need to respect what Joss and the others have already given to bring Processwire to where it is now. I would say that the best way to express what you want is to get building then show us.

Looks nice

So, I am nearing the completion of this site and I suddenly notice that just beneath my navbar a line of text has appeared. What? I didn't put that there! How long has that been happening? Well, I have been messing with a couple of functions, so that must be it. I delete them, but it is still there. Oh. I delete more off the page. Still there. I look at the source. Whatever this is it has effectively chopped my <head> in two - half of it is now sitting inside the body tags. I look at the head.inc and delete quite a lot of it. Still there. The text actually sort of relates to some of the info on the page. So I delete a couple of fields from my template-file. Still there. I turn to another page - same problem, And another. Same problem. Try one with a different template. Same problem. Then another one. And that one hasn't got it. Huh? It is the same template I started with! Okay, if in doubt, read the text. It dawns on me that the text is a list of child pages - the last one I tried does not have children. So, where on earth is it coming from? On a hunch, I open my functions file which contains a lot of the logic for this complicated site and search for "children" The search takes me straight down to the bottom of the page to three little lines all on their own and not in a function: foreach($page->children as $child){ echo $child->title; } What are those doing there? Then I remember. https://processwire.com/talk/topic/8176-end-user-usability/?p=79356 Earlier today I posted a comment on the forum and wanted to add a little bit of code. To make sure I made no mistakes, I quickly typed it on whatever I had open in Sublime text, copied it off and promptly forgot all about it. It has just cost me an hour of cursing. Very, Very, Very, Very Silly And a few stupids too!

You might want to give magnolia a try. It's pretty nice (I'd choose it if we would be using java): http://www.magnolia-cms.com/ See:

Er ... depends how brave you are.... Liferay. However, it is a monster and though incredibly versatile and powerful, it takes a huge amount of learning. The advantage, though, is that because it is actually a portal system, the CMS side is just a plugin portlet, as is all the other functionality. So you can build and run a thousand dedicated sites on it. And it also runs as a container, so you can run a php application within it. So, you could add ProcessWire to it, in theory. And it has hooks for everything, so you can get the Liferay and PW database chatting away too. All a bit over the top.... I am sure there are some smaller beasties that make more sense!

Here is a quickie! If you use repeaters for sections on a page (good use for repeaters that) then you may want to use anchors to help navigation. The most obvious thing to use is the "name" of the repeater, because repeaters are actually pages and the name field has no spaces. Ah! But there is a problem with repeaters! They are stored as pages under admin, in your page tree, and if you go and look at one you will see that its "name" looks something like: 1401972317-1689-1 Which is less than useful. The next thing to use is the "title" field, but that has spaces, uppercase and the rest. So, here is a quick and dirty little function that I found on StackExcahnge function seoUrl($string) { //Lower case everything $string = strtolower($string); //Make alphanumeric (removes all other characters) $string = preg_replace("/[^a-z0-9_\s-]/", "", $string); //Clean up multiple dashes or whitespaces $string = preg_replace("/[\s-]+/", " ", $string); //Convert whitespaces and underscore to dash $string = preg_replace("/[\s_]/", "-", $string); return $string; } Now all you have to do is use it in your foreach loop for your repeater: function myRepeater (){ $repeaters = wire("page")->my_repeater; $out = ""; foreach($repeaters as $repeater){ $anchor = seoUrl($repeater->title); $out .="<a name='{$anchor}'><h3>{$repeater->title}</h3></a>"; } echo $out; } And there you have it. Your anchors are now-like-this and your SEO is just that tiny bit better. Note: There is probably a neater way to do this, but this is nice and clear and does everything, I think.

Sounds like this would benefit from separate "not" / "negate" checkbox, or something like that. Just saying..

Just in case you also stumbled upon my Foundation 5 profile. This is outdated, too because I'm not using it anymore. But in the readme.md are instructions how to update.

Hi Christophe Always best to use the latest version, however, nothing need converting. When developing with a framework, I strongly suggest you start with the blank profile so you are not fighting against any existing systems. Then, add the framework in exactly the same way as you would for a static site (so, using the authors recommendations), but in the /site/templates folder. Next, I would suggest that using your home.php template you create a complete html page from <html> to </html>, just as suggested by the framework authors. Don't worry about anything ProcessWire, just put straight html in there. Note; see my tutorial about referencing css and javascript - this is the only "conversion" you need. Once that is all up and running, then you can split it up however you want to proceed. If this is all new to you, I suggest you just go for greating a head and foot and include them into the top and tail of your template. You will soon work out your own system. By the way, if with Foundation you use the scss files and work in SASS, then Prepros is a very good, all in one windows/mac solution which works well - you wont need to install ruby or compass, it is all included.

hi Christophe, I think it's better to translate inside PW instead of working with a text-editor. It's not perfect to work with, but doable. See the image. If you upload empty files, you will get all translatable strings as empty inputs. Example: 'Template' is empty, because it's the same word in german. 'Created' will be translated with 'Erstellt'. Imho best practice: take the existing french files, compare filenames with the empty-pack. Some files will not be used anymore. Then put the rest of the fr-files in the empty-pack (replace the same filenames). At the end you should have 122 files (for stable PW). Upload them and start translating.

ProcessWire IS successful. I've not read all but think it's all kinda way off to what PW is in its philosophy and core. Sorry, but I usually am too lazy to read more than 2-3 paragraphs. You need to work on your end-user usability (me reading your post, or not).

Great topic! And really nice to see that everything that has been outlined and planned got its way into reality. I am trying to update russian translation right now and find it difficult to find the file with the string I want to translate. Am I completely missing the search and find capability, or is it not in place? If it is really not there, I think it would be great enhancement to find translatable string by text in default language.

Upcoming update: Blog version 2.2.1. (dev) Summary of Changes: All main methods that render HTML output are now configurable via a parameter/argument $options These changes allow much greater control of your Blog features' layout/output. I will provide examples later but most of the below is hopefully self-explanatory. Please note these changes supersede those introduced in version 2.1.1 and 2.1.0 (some name changes to array indices + some additions). None of the changes will break your existing install if you are using the stable Blog branch. However, if you updated to 2.1.1 on the dev branch, AND started using some of its new optional features, some minor modifications to template files could be required (i.e, following the examples shown in 2.1.0, e.g. for renderPosts(), $featuredImage parameter is now $options and covers all aspects of rendered posts, not just featured images. E.g. to display a featured image on a summarised post, use array('post_small_image'=>xxx) as shown below. I have updated the dev branch for testing/comments, thanks. I will update the docs once I merge to master branch. New Default Options in MarkupBlog Methods renderPosts() //default options for various aspects of posts $defaultOptions = array( 'post_count' => 1,//0=off, 1=on - for the count in: Posts 1 to 5 of 15 'post_count_text' =>$this->_('Post'),//e.g. Posts 1 to 5 of 15 'post_not_found' => $this->_('No posts found.'),//message when no posts found 'post_author' => 1,//display name of post author: 0=off,1=top(below post-headline),2=bottom(in post-foot) 'post_author_text' => $this->_('Posted by'),// 'post_date' => 1,//display post's date: 0=off,1=top(below post-headline),2=bottom(in post-foot) 'post_date_text' => '',//e.g. Posted by author 'on' date 'post_more_text' => $this->_('View More'),//for $small posts - link text to full post 'post_categories' => 2,//display post's categories: 0=off,1=top(below post-byline),2=bottom(in post-foot) 'post_categories_text' => $this->_('Categories:'),//e.g. 'Categories', 'In', 'Filed under', etc 'post_tags' => 2,//display post's tags: 0=off,1=top(below post-byline),2=bottom(in post-foot) 'post_tags_text' => $this->_('Tags:'),//e.g. 'Tagged', 'Related', etc 'post_small_allowable_tags' => '',//holds string of HTML tags for strip_tags $allowable_tags. Needs to be in format '<code><p><img>' 'post_small_headline_tag' => 'h4', 'post_large_headline_tag' => 'h2', 'post_comments' => 1,//show comments info? 0=off,1=comments count top,2=comments count bottom,3=comments count top & bottom 'post_zero_comments_text' => $this->_('No comments yet'), 'post_comments_text' => $this->_('Comment,Comments'),//title in anchor comments icon + post-foot comments text, e.g. '2 Comments' or '1 Comment'. Must be in 'singular,plural' format 'post_comments_label' => $this->_('Comments:'),//this appears in post-foot, e.g. 'Comments': 2 Comments //## featured images ## 'post_image_alt' => 'description',//defaults to $image->description. Otherwise other stated field on the page, e.g. = 'title' 'post_image_tag' => 'featured',//string: image tag to look for in blog_images//@@todo - need translation here? //** small/truncated post featured image ** 'post_small_image' => 0,//display post's featured image: 0=off,1=top(above post-headline),2=bottom(first item in post-body) 'post_small_image_width' => '',//no width manipulation of featured image if this is blank or 0 'post_small_image_height' => '',//no height manipulation if this is blank or 0. Note, if size is true and both width and height > 0, use size() instead /*size: - image will be resized to exact dimensions -> $img = $image->size($x, $y) - where $x = 'width' and $y = 'height'*/ 'post_small_image_size' => false,//if 'size' = true AND both width and height > 0, this kicks in //** large/full post featured image NOTE: for full posts, to avoid duplication we only pull image from blog_images ** 'post_large_image' => 0,//display post's featured image: 0=off,1=top(above post-headline),2=bottom(first item in post-body) 'post_large_image_width' => '',//no width manipulation of featured image if this is blank or 0 'post_large_image_height' => '',//no height manipulation if this is blank or 0. Note, if size is true and both width and height > 0, use size() instead 'post_large_image_size' => false,//if 'size' = true AND both width and height > 0, this kicks in ); renderTags() //default options for tags $defaultOptions = array( 'tags_posts_text' =>$this->_('post,posts'),//come in the format 'singular,plural' for e.g. 1 'post' ); renderCategories() //default options for categories $defaultOptions = array( 'categories_posts_text' =>$this->_('post,posts'),//come in the format 'singular,plural' for e.g. October 5 'posts' 'categories_not_found' => $this->_('No categories to display.'),//message when no posts found 'categories_more_text' => $this->_('View More'),//link text to view all posts in that category ); postAuthor() //default options for author widget $defaultOptions = array( 'author_text' => $this->_('Author'),//text next to author title|name 'author_thumb_width' => 100,//no width manipulation of author thumb if this is blank or 0 'author_thumb_height' => '',//no height manipulation of author thumb if this is blank or 0 'author_thumb_alt' => 'title',//defaults to $author->title. Otherwise other stated field on the page, e.g. = 'title' or if 'description' then $image->description ); renderNextPrevPosts() //default options for next/prev posts $defaultOptions = array( 'prev_post' => '<',//tag/text for previous post, e.g. «, «, etc, i.e. << >>, etc 'next_post' => '>',//tag/text for next post, e.g. ›, etc 'prev_post_text' => 'title',//if title or not empty: will show title of the prev post. Otherwise show specificed text, e.g. 'Older entries' 'next_post_text' => 'title',//if title or not empty: will show title of the next post. Otherwise show specificed text, e.g. 'Newer entries' ); renderComments() - was already configurable; here showing new additions only //ADDITIONAL default options for comments $defaultOptions = array( 'comments_success' => $this->_('Thank you, your submission has been saved.'), 'comments_error' => $this->_('Your submission was not saved due to one or more errors. Try again.'), 'comments_text' => $this->_('Comment,Comments'),//comments text, e.g. 2 'Comments' or 1 'Comment' next to comments count (div#comments). Must be in 'singular,plural' format 'comments_list_empty' => $this->_('No comments found.'), 'comments_list_reply_text' => $this->_('replied to'), 'comments_by_text' => $this->_('Comment by'), 'comments_post_text' => $this->_('Post a comment'), 'comments_prev_text' => $this->_('Back'), 'comments_next_text' => $this->_('Next'), ); renderArchives() //default options for archives $defaultOptions = array( 'archives_posts_text' =>$this->_('post,posts'),//come in the format 'singular,plural' for e.g. October 5 'posts' 'archives_month_view_all_text' => $this->_('View All'),//'view all' that month's archives if limit set on amount to list );

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.

Notepad++ anyone? I don't know if it counts as an IDE but it works fine for me with its plethora of plugins although I may need something more IDE-ish in the future...

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>

I didn´t agree with you for the German language! May be in Finland the moste People speek English?? But in Germany the most is translated for you (TV, cinema, ... the daily live). OK you say for "site builders" but here we are... on the other hand we want that PW should be more "public" and on the other side "english" for ALL is ok - i thought (that is only my opinion) for more "public" in Germany we NEED a full German translation. (In Finland could it be other?!) hmm i´m disagree with you about this. Ok it would be right that for the word "Admin" we didn´t need a "better" Translation (because we have enough "Denglisch" in our Language) but i thought it would be more confusion (see my poste above - and i´m not sure if i the only one??) when i go through the Translation and see - 1 blank, 2 blank, 1 blank, ... that sounds for me it´s not complete!! So i prefer a whole translation state. Only my 1 cent to this topic