ProcessWire Dev Branch

[arjen]

It's not labeled as stable, but it is pretty stable. I run it on one site without errors. Ryan also runs it on his bike website - I suppose without errors.

If you use git you could check your current branch to be sure. When using a zip I would recommend checking a file like this which is recently edited (2 days ago) and compare that with your download. This way you know it it's the latest version.

[pwired]

When I go to git here:

https://github.com/ryancramerdesign/ProcessWire/tree/dev

I only see this ProcessWire 2.3. PHP 5 based content management framework. This is the current production version. It says current production version so this version 2.3 is not the latest dev version.

What is the latest dev version ?  2.3.1  or maybe by now 2.3.2  ?

I know this post but there is no download link

http://processwire.com/talk/topic/3768-processwire-231-dev-branch/

Sorry I am not so good with git.

Where is the link to git holding the latest dev version

And where can I download the latest dev version as a zip file ?

Thanks

[arjen]

Don't focus on the title, focus on the files. Go to github, switch to dev branch and download the zip. I just checked and the zip seems to be the latest dev version.

[pwired]

Don't focus on the title, focus on the files. Go to github, switch to dev branch and download the zip. I just checked and the zip seems to be the latest dev version.

I did that and downloaded the following file : ProcessWire-dev.zip  Windows File Size 5.69 MB (5,969,652 bytes)

In windows properties I see a tab "comment" with following contents f121cb0f954e14d31941a43d0a345b392c91cd6a

It doesn't say any dev version. How can I know from this the dev version

When I open the zip file and view the readme.md the first line says # ProcessWire 2.3

Maybe it is just me but where can I see the dev version of this downloaded zip file ?

It should be 2.3.1 or 2.3.2

[arjen]

In both branches the readme.md says 2.3. You can just install the zip and check in the footer of the admin which is supposed to say 2.3.2. You can also check the system version by running this code:

echo $config->version;

or

echo $config->systemVersion;

Like I said: I checked and the zip is the latest dev. No need to worry mate

[pwired]

Anyway the dev version should not so difficult to be found. Simply in the file name or at least in the readme.md

Sometimes I have this feeling that websites, cms-ing and coding is more like a digital battle field.

I had it for today. After 10 hours gonna turn off my laptop and look for the fridge, the sofa and my tv.

Arjen, thank you for being so patient and taking the time to explain where to find that dev version.

[Pete]

It's whichever version is under the Dev branch on Github - the verisons in the readme or anywhere else in the Dev branch are irrelevant.

The point about the Dev branch on Github is that it will always contain the very latest code regardless of whether a version number has changed or not - if ryan changed the version number every time he committed a batch of new code we'd be on version 2.3.712 as he has uploaded something new to the dev branch 712 separate times since v2.3 was created (or maybe since 2.2... can't remember if this was a new Git repo for 2.2 or 2.3). These might be a few updated files or just a single line of code, but every time new code is pushed to Github it's a separate "commit".

Long story short, version numbers don't change with every commit to Github - they change when those commits are merged with the stable (Master on Github) branch. The dev version isn't really mentioned on the PW site itself as it's for developers who wish to tinker and other curious parties and is not generally recommended for live sites - it's "beta" really, at least the changes are - but some of us can't help ourselves

[pwired]

Pete, thanks for the extended explanation. This is one of those knowings you won't normally find in the forum neither on github. You have to be "around" for some time to know this as something obvious. Which also gives some credit to Zahari Majini posts. Sometimes "getting there" takes a while of flinching.

[kongondo]

On dev branch...

 

echo $config->version;//returns 2.3.2 - documented here

 

echo $config->systemVersion;//returns 3

 

What gives?

 

Edit:

 

OK, answer here for $config->systemVersion

 

class SystemUpdater extends WireData implements Module, ConfigurableModule {

	public static function getModuleInfo() {
		return array(
			'title' => __('System Updater', __FILE__), // Module Title
			'summary' => __('Manages system versions and upgrades.', __FILE__), // Module Summary
			'permanent' => true, 
			'singular' => true, 
			'autoload' => false, 

			/**
			 * This version number is important, as this updater keeps the systemVersion up with this version
			 *
			 */
			'version' => 3, 
			);
	}

	protected $configData = array(
		// systemVersion generally represents the DB schema version, but 
		// can represent anything about the system that's related to the individual installation.
		// 0 = the first version when this module was created, should remain there. 
		'systemVersion' => 0, 
		);

Edited August 1, 2013 by kongondo

[ryan]

systemVersion is just an internal thing so that PW knows when it needs to apply something like modifying the schema of the database. Most ProcessWire versions don't involve changes to DB schema, so I wanted to have a separate way to track that. It's automated behind the scenes, and the systemVersion isn't useful for much else. If you ever see ProcessWire give you a message in the admin to the effect of "Applied system update #3", then it means it just made some adjustment in the system (likely to the database) and incremented the system version. 

[pwired]

This makes all perfect sense and be obvious to github workers, but not everybody is contributing and committing on a project done through github. How many are doing commitments on pw or on other projects through github and how many are only using pw ? Hence the number of people not being familiar with github as a dev platform and not everybody knows that systemversion is just an internal thing so that PW knows when it needs to apply something.

On top of that everybody is familiar with downloading software and programs with a clear visible version number in the filename or in the readme.txt

When posts show up in the forum saying something like "we are now on dev version 2.3.2 with this now stable and that improved" some people start looking for where to download this dev 2.3.2. They expect it to find the same way just as they download software and programs with a clear visible version number in the filename and inside the readme.txt.

They end up looking at github but nowhere it says dev 2.3.2. Confusion starts. We download anyway but see only the word dev in the filename, we don't see a dev version in the filename. More confusion. After the download we open the zipfile, we don't see a familiar readme.txt but a readme.md. Fine we don't understand .md but we see at least the word readme so that will do but in the first line it says # ProcessWire 2.3

- more confusion, what have I just downloaded ?

Is this scenario so hard to picture or is this another example of something that happens only to newbies and designers and never happens to coders ? (who commit on github so that makes sense)

Of course I understand you can't change the dev version after every commitment, but it could after every x commitments or after major commitments and put it in the file name and in the readme.md

Why readme.md anyway and not simply readme.txt like the other .txt files in the zipfile ?

[ryan]

not everybody knows that systemversion is just an internal thing so that PW knows when it needs to apply something.

Please don't pay any attention to systemVersion. I was just trying to explain what it was for those interested, but it's not something anyone but core devs need to think about. 

On top of that everybody is familiar with downloading software and programs with a clear visible version number in the filename or in the readme.txt

The dev branch is not an official release and I want to be careful about anything that might present it that way. People don't even need to know about the dev branch unless they are interested in helping to test or develop ProcessWire, or (in this case) take advantage of the multi-language updates before they appear in PW 2.4. It's a branch that gets updated a few times a week, sometimes even daily or more. For a dev branch like this, the commit ID is the version, and the commit log is the README. Everything on dev is basically "being prepared" for an official release, so you wouldn't typically have separate README files for master vs. dev, etc., because dev is not a release, it's a branch working to eventually become a release. It's best to follow the commit log of the dev branch to see what's happening. It's also best to use the dev branch with Git (git checkout dev), and not by downloading a ZIP file. Typing "git status" will tell you what branch you are on (master or dev), and "git pull" will pull in the latest version instantly.

I understand that Git can be confusing and a whole lot to figure out (I'm still learning it myself), but we are getting into the nature of how Git and software development work. The audience here is intended to be developers and testers, where Git is the standard. It's not supposed to be neatly packaged, versioned and ready for the consumer, and will always take more time investment on the part of anyone using it. We want users to have some experience with Git when using the dev branch because we are asking them to help test, report, and potentially fix issues through the GitHub system. I think part of the confusion here is just that we are getting very close to a 2.4 official version release and the dev branch is quite stable. So the distinction between official release and dev is probably more blurry than usual. Without thinking much about it, I've been casually telling people to use dev when it seems to make sense. But that will change as we hopefully release version 2.4 soon. 

[ryan]

I pushed an update to the dev branch yesterday that should solve the issue of broken links in textarea/HTML fields when migrating a site between a subdirectory and root, and any other scenario that involves a change to the site's root path. This was previously solved by the the PageLinkAbstractor module, but I've always been on the hunt for a solid core solution. The solution I put in is really basic and simple, and I'm not 100% positive it's the right one, but here's what it does. When editing the settings for any Textarea field, you now have a "Content Type" setting: 

If you select "Markup/HTML" then it signals FieldtypeTextarea to look for certain attributes to convert when you save the page. Specifically, it's going to convert any local pointing <img src='...'> or <a href='...'> attributes to assume that the site's root is always "/" (at least from a DB storage perspective). Then whenever the field is loaded, it converts them back to the site's actual root. Using this method, any links or images placed in your TinyMCE/CKEditor textarea fields should continue working normally no matter where you move your site. 

Like PageLinkAbstractor, it doesn't retroactively apply to existing links. It only applies to links/images saved on pages after enabling the option. Unlike PageLinkAbstractor, it keeps the original code in a state that's still portable regardless of whether you later turn off the option or pull the text directly out of ProcessWire's DB. It's not yet had a lot of testing yet, so don't choose "Markup/HTML" unless you want to test it. As of 10 minutes ago, it's now compatible with TextareaLanguage as well. 

[ceberlin]

Hi Ryan, this sounds VERY interesting. Does that mean that the PageLinkAbstractor is now obsolete? And if not de-installed (because that could mean broken links and lots or repair work, if I see this correctly) - could there be a conflict having both active at the same time?

[ryan]

PageLinkAbstractor isn't obsolete because its doing a little more than this solution is. PageLinkAbstractor is abstracting the links to page IDs, meaning it has the benefit of being able to keep links consistent with pages that move. I also don't see any potential conflict between the two, but if you are using PageLinkAbstractor, then there's no reason to enable the Markup/HTML option in your Textareas. 

[Martijn Geerts]

I'm trying to update PW2.3 to PW2.3.3. 

But getting error:

Parse Error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM (line 273 of ......./wire/core/Modules.php)

The version of PHP on the server. 5.2.17. (I know this is old, but hard to update & still higher then the 5.2.4)

If I look at the source, there nothing weird about the double colon.

[Soma]

Have you tried delete /site/assets/cache/...?

[Martijn Geerts]

Yep, also deleted sessions.

[Soma]

I got same error and empty cache folder did the trick. Same as a modules refresh in admin.

[Martijn Geerts]

Yep followed Ryan's instructions about the modules cache. And usually I delete caches & sessions to.

Here, I gonna move the development of this site to a server with a newer PHP version. So for me this problem is solved now.

But open to test if Ryan needs more information. 

[Martijn Geerts]

Thank you Roope !!!

Gonna try tomorrow if your fix will fix my issue!

Parse Error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM (line 273 of ......./wire/core/Modules.php) 

possible solution from Roope

Lookin' in dev branche now. I see Ryan has made these "fixes" 6 hours ago.

Thank you very much Ryan & Roope !

I couldn't wait till tomorrow to see if it was fixing the issue. So I tried and it did.   

Edited August 15, 2013 by Martijn Geerts

[ryan]

I actually ran into this issue myself on Wednesday when I was upgrading a client's PW install running PW 5.2.17. I corrected the issue and committed it yesterday morning when I got an email about this thread. I hadn't been through the issues list this week yet, but looks like Roope submitted the exact same fix more than a week ago. I have no idea why PHP 5.2 doesn't like the syntax, or why I changed the syntax in the first place, but the latest dev should be fixed to work with PHP 5.2.

[Martijn Geerts]

Yep, tnx just satisfied a customer today with your fixes !

[owzim]

I am having trouble getting the different versions downloaded.

On github there is a commit called "Bump version number to 2.3.3" so if i checkout that commit that's ok, but what about all the other minor version steps? I can't find them.

I'd love to get 2.3.1 and 2.3.2 as well.

[Martijn Geerts]

In 2.3.3 it looks like Textformatters are not applied over concat fields. Textformatters over other fields work.

Oops, sorry:

it was Page List Image Label what disabled the textformatter.