Leaderboard

I believe that OP was referring specifically to D8, and how it relates to PW. According to the Drupal team, they've changed a lot since D6-7, so I don't think it's such an unreasonable question to ask, and personally I'd love to hear some proper insights on the matter -- preferably from someone with solid D8 knowledge, not just past experiences with earlier versions Taking a look at the D8 marketing materials, it seems like they're going to a good direction. Some of their new features I like, some I don't like, but in the context of Drupal they probably all make sense. Either way, it seems to me that much of what they've been adding ProcessWire, one way or another, already provides. The way they're touting HTML5, mobile first, etc. makes me think that the markup generation part, which is one of the biggest problems (in my opinion), might not have changed much either. The developer API and theming system still seem complicated to me, but I'm used to working with custom applications, application frameworks and ProcessWire specifically, so my views are probably biased. It also seems that these are very much separate entities, quite unlike how it works in ProcessWire, where the API is a key to everything, everywhere. Anyway, this is exactly why I'd love to hear some unbiased opinions

I think we would have to put together kind of an active “Shop Development Group”. I love coding, but I’m definitely not that much a developer to lift a task like this. But I have some ideas on how to structure the modules to achieve a maximum of flexibility regarding how to layout your shop within the page tree. Splitting the challenges is small packages may be the key to success here. I’ll try to sketch my ideas. Could be a point to start. Maybe, when this thing gains some momentum, we could create an own github account for this where all shop modules are bundled and specific discussions on functionality can happen in the issues section. Who would be interested in contributing to a project like this?

I completely rewrote the module kinda. New version just committed earlier: See readme here for more infos: https://github.com/somatonic/MarkupSocialShareButtons There comes now a GUI in the module config screen to select themes (with live preview), and configure all options like links and url params. Theming has changed a little to make things easier, and the bundled themes use PNG icons instead of SVG. Edit: updated first post too.

MarkupSocialShareButtons This module outputs a list of share links for the following services by default * E-Mail (kinda extra) * Facebook * Twitter * Google+ * LinkedIn * Thumblr * Reddit (off by default) * Pinterest (off by default) Usage examples echo $modules->MarkupSocialShareButtons->render(); This outputs a simple UL list with links <ul class='MarkupSocialShareButtons cf'> <li class='mssb-item mssb-facebook mssb-popup'><a href='url'><i>facebook</i></a></li> etc ... </ul> Config Screen See more details and examples on github or modules directory https://github.com/somatonic/MarkupSocialShareButtons http://mods.pw/8j

I think that should be a metaphor for life

get will get it, regardless of state.

You simply do not listen. NOTHING here is about the core. This is about a module idea. It is completely optional. It does not need to be part of any translation system if that is not wanted. It does not even need to be taken up by module developers if they do not have the time. So, will you stop hijacking my ideas my introducing things that I was not talking about. You simply bring discussions to a grinding halt. Consider this topic now closed

Yes, we all know that. There are several links to this topic from this one already (just read a couple of previous posts). But I think this group is still a good idea, because: Antti's new shop offer is not out yet and is delayed (as you pointed with that link). His new shop is not going to be free (I guess still open source but not free to use). I think it is good to have a free alternative in you pocket. The communiy discussion will benefit us all (Antti's shop included) even if will not turn out as a separate product. @dazztweb - those are the same point as yours - need to learn to type faster ))

Finally got that fixed. I had downloaded and installed "AdminRestrictPageTree" and assigned to "guest" and "manager". I assumed it would just hide the actual full tree leaving my listerpro lists of pages i want managers to be able to edit. No idea why guest is in there as they can not access that page anyway. Instead it rendered everyone unable to login due to a page redirect loop. I guess the issue was my own fault, I did not have a page to redirect them to, as I did not understand it was going to stop them getting to the admin page altogether. Guess that will teach me to be sure i know what i am doing with contributed modules. Have removed that module now after editing database to remove restricted roles and once again gaining access to the site admin. I guess the reason I could no longer get in was due to the guest role being added to restricted users.

I think the big difference between the points of you both is in the definition of docs. Lisandi sees them as documentation for the CMS as a whole. So there are docs about the UI, modules, for admins, for designer and so on. Because each of them has to somehow work with the cms, while each need to learn different stuff. I would consider most of this information as bloat for the actual cms. Designers and Developers do have enough resources here on the site and clients should have no hassle with the basic UI functionality of processwire after a bit of initial introduction. Joss on the other hand is talking about a documentation the developer/designer is setting up only for the user/client. This is very much sitespecific as even most modules can be used differently on each page, not talking about different sitetemplates. One could see them as site maintainance guidelines / helpers.

You shall not objectify people, but you could objectify Textfields!!! Github: https://github.com/owzim/pw-fieldtype-yaml Module page: http://modules.processwire.com/modules/fieldtype-yaml/ Summary Field that stores YAML data and formats it as an object, when requested. Setup After installation create a new field, let's say called "people" and assign it to a template, or just edit an existing text-based field and choose Yaml for the type, save! In the Details-Tab you have an additional option, the Texformatter option is removed, because it does not make sense in this case. Parse as Default is WireArray/WireData, the data can also be parsed as Object or Associative Array. Associative Array is the fastest and the default output by the used Spyc parser, WireArray/WireData might be the slowest, but it's also the most feature rich. You can access properties like you are used to with pages or fields, like $page->person->get('title|name') or $page->people->find('age>30'). Usage Now, in your just created field you can put in some YAML like this: - name: Jane Doe occupation: Product Manager age: 33 hobbies: - running - movies - name: John Doe occupation: Service Worker age: 28 hobbies: - cycling - fishing In your template, or wherever you are accessing the page, you would use it like any other ProcesssWire data (if you set the parse option to either WireData or Object): $out = ''; foreach ($page->people as $person) { $out .= "Name: {$person->name} <br>"; $out .= "Occupation: {$person->occupation} <br>"; $out .= "Age: {$person->age} <br>"; $out .= "Hobbies: <br>"; foreach ($person->hobbies as $hobby) { $out .= "- {$hobby} <br>"; } $out .= "--- <br>"; } echo $out; More info about YAML: Complete idiot's introduction to YAML Specification Wikipedia Acknowledgements I've used a namespaced version of the Autoloader class from Template Data Providers The YAML parser is a namespaced version of Spyc Edit: updated the repo link

Just a very vague idea here. The idea is to create a set of help pages in the back end. Not the wonderful notes system from Soma (which is ever useful), but a centralised system that is partly automated. So, for each module two sets of docs are written by the developer - admin and user. When a module is installed, these are automatically added to the backend help system. This is permissions based, so the superuser can decide who can see which set, plus make exceptions for specific modules. This includes switching some of the docs off entirely if it is thought they might confuse or are simply not needed. (Might even allow devs to pre set this if their mod adds functionality where docs are unlikely to be needed) Additional notes can be added manually to each of the docs at either the head or tail so the admin can add anything specific to that particular website. When modules are updated (which might include updates to their docs) these additional notes are not affected and still work. Extra docs can then be added by the admin for site specific functionality that are not related to a specific module. The entire lot can be viewed in the admin as a cohesive set or can be viewed as in context help in a popup. Sorry! This system does put a pile of work on module developers (and even more on Ryan), but the result if worked out properly could help the day to day usage of the admin enormously and makes ProcessWire even more accessible to potential clients The two sets are key here. On other systems where help is built in, it is often aimed at the admin not the user, so the poor user gets flooded with information they might not understand and do not have the permissions to use even if they do. This way, each user, admin or other, just gets the bits they need which is a lot cleaner!

You may also need the following at the top of your htaccess file: # Use PHP5.4 as default AddHandler application/x-httpd-php54 .php I had set my site up in a subdirectory for the client to see and it worked fine, but when I moved it to the top level, it threw a 500 server error and the error log showed "unexpected T_PAAMAYIM_NEKUDOTAYIM." So I checked the htaccess file of the WordPress system that I was replacing and there was the magic line that solved the problem. Thank you, jsantari for asking and arjen for your answer.

Thank you Kongondo! By the way. Your tutorials on Kongondo.com are very useful. Even I can understand:-)

I think most of us here know about apeisa's new shop module that he is working on and good luck to him. The only thing I can say is that it doesn't look like a community project but appears to be a private enterprise as it is in 'closed beta testing' and has a price tag on it. I have no problem with that and might purchase it myself if it is what I need but it would be great to get an open source working project out there that we can all work on and contribute together a bit like virtualmart for joomla even though I know it is a mammoth task.

Let's do it, Oliver! Why don we start with creating a separate topic for that. I do not want to steal your credit for the idea, so go ahead and do it if you will. Not sure where this shall lead us, but it is the only way possible, as noone is going to do it for us. But if someone is already doing it for us, please uncover yourself and join us (or let us join you) .

Thanx so much. It works like a charme

OMG. Animated gifs! I suddenly feel so retro. But seriously, PW with GD-lib doesn't support this. And as your request now seems to be the first that arrives here, it shows that this is a really rare case today. Teppo already has done a good recherche on that and it shows that this is not a small piece of work. I don't think that Ryan would want a full support for that to go into the core. (If not more than 20% or 30%? of the users need this it has to go into a module). But you need a quick solution now. You may check if your host supports IMAGICK, (not 'ImageMagick', but 'ImageMagick' through a PHP-Extension called 'Imagick'). If yes, install and try out ImagickResizer. I don't know if it supports animated GIFs yet, but there is a good chance it does. If this doesn't work for you, can you display them just with "resizing" by css dimensions? (Is this the only case where you need this) If above both doesn't work, I think the only thing what can be done quickly is to implement a check for animated GIFs into the Imagesizer (or maybe as a workaround, into your template code) and if it is a animated one, redirect the manipulation to one of the mentioned LIBs at StackOverflow.

Hi there! Your first image seems to be 500x500 in size, actually, just scaled down using styles. Could that be the original size, perhaps? Second image has "500x500.300x0" in it's filename, which looks a bit weird (are these both added by ProcessWire?) and is actually 300x300 in size. Guessing this is the downscaled version. Haven't tried these with ProcessWire, but I've seen image resizing destroy animations in GIF files before. That might be happening here too -- Horst should probably take a look at this, he's the one who knows best what's happening. A very quick Google search resulted in this thread, which seems to suggest that GD resize might need extra work to support animated GIFs For the record: if possible, I'd suggest that you create a new GitHub issue for this.

Is that a question??? You don't know what Ryan has under his sleeves. Fun times ahead.

Because it is within a php echo statement already, this will work: <img src="{$config->urls->site}assets/images/IcoMoon/Icons/SVG/globe.svg" class="logo"> To expand on owzim's comments, I try to avoid escaping double quotes. Use a mix of single/double quotes to make it cleaner. So you could have: echo '<img src="'.$config->urls->site.'assets/images/IcoMoon/Icons/SVG/globe.svg" class="logo">'; or: echo "<img src='{$config->urls->site}assets/images/IcoMoon/Icons/SVG/globe.svg' class='logo'>";

Yep, they are all there. You need to press the advanced tab to show the system ones.

Hello, PageTable is described as a leaner way to enter large amount of repeatable data into the admin backend, possibly with different sets of fields (think different templates). The main advantages compared to the Repeater are: 1. PageTable can save new pages where you tell it to. Repeaters are saved deep down the Admin pages and are given cryptic names. 2. One PageTable field can make use of several different templates. Repeaters play according to the "One repeater = one template" rule (roughly put). PageTable is a PageArray, so relevant methods are applicable. For example, here is how to add and remove items from a PageTable field using the PW API: // create a new page // IMPORTANT: your PageTable field must be configured to use template 'basic-page' in the field Setup tab $newpage = $pages->add('basic-page', '/about/', 'address', array('title' => 'Write to us')); $page->of(false); // add the newly created page to 'pt' which is a PageTable field $page->pt->add($newpage); $page->save(); Here is how to remove the first item from a PageTable field: $page->of(false); // 'pt' is a field of type PageTable $page->pt->get(0)->delete(); $page->save(); That's a quick overview of this new field type. Give it a bit of your attention, it's quite promising. Cheers, Valery.

To be honest, part of this is plain laziness - by all of us. What I keep trying to find time to do is to create a really good catalogue as a starting point - and that can be done in PW without any additional tools. And THEN look at what I need. I suspect that the hill will be less of a climb once the first bit is done. So, perhaps the REAL conversation should be: what is the ideal catalogue structure in PW? And then go and do it.

I only tested Atom very briefly and some time ago, and I don't think I have given Brackets more than a short glance. At first sight, they look and feel very much as if they're trying to be “the better Sublime Text” without really offering (for me, which is totally subjective) any benefit. Instead, I'd have to go through the hassle of configuring a new editor to my liking, which is something ST (again, for me; very subjective) was really good at. My ST config is basically non-existent, I pretty much use it the way it comes. Also, there's modules/plugins – I use only a handful in ST, and I'd have to check if something similar exists for Atom or Brackets. Bottom line: if you're working with code every day, switching editors is similar to replacing an arm or something. (I sometimes still catch myself using keyboard shortcuts I used in Emacs for about 10 years on Linux.) Despite the (true) facts that ST development is kind of slow and the developer is not very transparent about development, any new editor would still (once again, for me) have to offer really convincing new features to get me to even think about switching.

I will get him to add a bit about servicing snowmobiles immediately!

There aren't any connections to the admin theme with this module. But installing AdminThemeReno would have cleared the modules cache, so I'm thinking that's most likely what was needed (a modules refresh). It will go into the core once I can add the option of FTP/SFTP/FTPS installation as an option for upgrading/installing modules and core. Your statement is true with Drumlapress, but not with ProcessWire as far as we know. While newer core versions add new security enhancements and such, running an older version of PW doesn't mean your site isn't safe. If a site is running smoothly and does everything the client wants, I tend to leave it alone. Even if upgrades are relatively safe and easy, there's always a rare chance that something will break and need an update as a result of upgrading the PW core or any module. There are plenty of good reasons to upgrade, but since there are no known security vulnerabilities in past versions as of yet, having a safe site is not currently one of them.

Morning Teppo! Well, in keeping with the way ProcessWire works this would be pages. So.... Probably the module would include two .md files as default: ModuleName.userdoc.md ModuleName.admindoc.md At install time, these are converted to pages if the docs module is installed. Working backwards... If the docs module is installed later, then it scans the modules directories and adds any of those files. That is the really boring basics. Administrating Docs Since these are now pages, this becomes a little easier. Under Admin in the tree there is a new parent - Docs. Under that two sub-parents - Admin and User. In each are all the relevant pages. Permissions are associated with the admin and user parents which are inherited by their child pages. These permissions govern who can see the docs; by default only admin can edit. Each page has the relevant md file imported into a CKeditor field. This means that the admin can customise the documentation if it is relevant. They can also add extra fields to the templates if they want to change the way docs are viewed. It would be as customizable as anything else in PW. Permissions can be changed for individual pages if there are several roles who need access to different things. Pages can be published and unpublished, as normal, so that if there is no need for particular docs they are not cluttering up the system. Languages If the various module developers are brave enough to do translations of docs, then maybe these can appear on language tabs. Perhaps some markup in the MD file identifies that this next bit is in a different language and what language it is in. A tab is created to match on import. That means the default doc language of the file also needs to be identified, of course. (Bit cheeky to assume it would be English!) Possibly needs the ability for the admin to add their own translations too. So lots of customizable bits there. Because this is the normal page system, the admin can add new pages talking about other stuff. If, for some mad reason, a third set of docs is required, or even a fourth, then another parent can be made - "Authors" or "Telephone Sanitisers" perhaps. Maybe even a publically available parent. Other pages can then be added under there. Viewing Docs The docs module would install its own templates, template files and a unique ckeditor field (so it does not muck up any existing bits). It would install its own search page too. It would show the docs in the language of the setup, if they are available, or it would show the default language of each doc if a specific language is not available. The docs ultimate parent page is the docs home page. It would list available docs on a permissions basis and include search (results on permissions basis). Access to this would be a link on the main menu bar. Linking to Docs This I am not so sure about. if a module has a "settings" page of some sort or some other setup procedurers, it makes sense for the module dev to make sure there are links written into the right part of the docs. The site admin, however, should perhaps have some way of adding links to admin forms to specific help pages. That would be something in the template , I would guess. Very complicated Docs Some docs may be very complicated and should be on several pages. This can use Ryan's multi-page markup system, though it will need something in the markdown doc that it can recognise and convert. So, most of this uses bits that are already available in PW - the biggest bit is the import.

Yes, it does. I have it run with nginx, so I don't care about the .htaccess Read the instructions on how to get hhvm running here: http://hhvm.com/blog/1817/fastercgi-with-hhvm You might need some tweaking and run into a lot of issues - hhvm has not been tested with ProcessWire. I also chose to let it run at port 8999 to be easily able to switch between hhvm and php5 for reasons of comparison. Your mileage may vary, but with a modern system your chances of getting it to work are better. Some stats using a fresh installation of Processwire with the site-beginner scheme ab -c10 -n500 http://pwtest.gurkendoktor.de/ php5-fpm: Concurrency Level: 10 Time taken for tests: 23.425 seconds Complete requests: 500 Failed requests: 253 (Connect: 0, Receive: 0, Length: 253, Exceptions: 0) Total transferred: 1902241 bytes HTML transferred: 1700241 bytes Requests per second: 21.34 [#/sec] (mean) hhvm: Concurrency Level: 10 Time taken for tests: 8.702 seconds Complete requests: 500 Failed requests: 232 (Connect: 0, Receive: 0, Length: 232, Exceptions: 0) Total transferred: 1900304 bytes HTML transferred: 1700304 bytes Requests per second: 57.46 [#/sec] (mean) This is in no way scientific. PHP does not use an opcode cache, which speeds up things a lot. on the other hand, hhvm gets better the "warmer" it gets (ie. the more load it gets). The nice thing is, that it still works with fcgi_cache: Concurrency Level: 10 Time taken for tests: 5.110 seconds Complete requests: 500 Failed requests: 491 (Connect: 0, Receive: 0, Length: 491, Exceptions: 0) Total transferred: 1912527 bytes HTML transferred: 1699527 bytes Requests per second: 97.85 [#/sec] (mean) Yes, there are some more "failed requests" - I blame this on ab Anyway, this is just plain ol' PHP Code. What would be interesting is to actually write a module in hack (the hhvm language) and see if this actually works. Because then you'll be able to harness hhvm's full power and experience an incredible performance boost. I'll figure this out later when there's time. More interesting it would be to fork the ProcessWire core and move it to hack. This would incredibly boost the performance, but brings other issues. But I guess this is too much of an effort, I myself wouldn't be able to do it

Sorry for poor communications from my part. New shop module is currently in closed beta testing. I am pretty busy at the moment (both work and personal), so there is not too much focus on this. For the pricing I am thinking something like 50€ - 99€ for single site license. Also currently (slowly) building full featured shop profile, that would be single purchase and free to use parts or fully as many times as wanted (single site license required for all new shops though).

There is a plugin, but I'm also aware that a new version of the forum software is out in the next few months. Couple that with the fact that Google can't see hidden forums (for commercial modules) and I'm not sure it's the best solution. Still, there is a plugin for the forums that's a whole $6 so I might look into that, but there's also a built-in integration with Sphinx search to look into that might be more suitable. Lots of options - I just need to find time to look at them. And then there's the possibility that some people still won't search but we can keep steering them gently in the right direction

When a client asks for "a website" with "easy management", explaining that ProcessWire is "an awesome framework for building just about anything" feels plain wrong and is unlikely to yield desired results. On the other hand, when client (or fellow developer) does mention the need for "an application", "framework" or "software platform", it's good to be able to match those needs too. Personally I really like the fact that ProcessWire has the ability to be both and would like to avoid emphasizing either *too much* over the other. If I needed a CMS, there would be a huge amount of other options available, and if I simply wanted to build an application I could (for an example) turn to Zend Framework and get the job done.. and so on. What ProcessWire brings into this equation is a well-balanced combination of features from both worlds. Each part supports the other, eventually making it more than the sum of it's parts. I especially love how easy and fast built-in admin makes mocking up data structures -- in fact it's such a smooth experience that the times I've built mock data manually for HTML wireframes etc. have been almost nonexistent lately. I find it faster to make fully functional features using ProcessWire than writing dummy directly with editor. And that, in my opinion, is why it's so damn good. Not that I really needed to explain it to anyone here, but my point is mostly that I don't see ProcessWire simply as a CMF or CMS or application framework or whatever. It's all of these combined.. and that's a good thing. I hope we don't get stuck discussing which one it is when that question can't (and shouldn't) have one single correct answer