Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
2011
The Pub / Re: git rebase is a joke...
« on January 12th, 2014, 12:49 PM »
All done, yay!
Now, all that's left to do is filter-branch to remove all occurrences of the languages folder (don't need to waste repo space on something that's already duplicated in its own repo), and the 'other' folder (aka the stash), although that one will be harder, and might stay in it.
Now, all that's left to do is filter-branch to remove all occurrences of the languages folder (don't need to waste repo space on something that's already duplicated in its own repo), and the 'other' folder (aka the stash), although that one will be harder, and might stay in it.
2012
The Pub / Re: git rebase is a joke...
« on January 12th, 2014, 09:32 AM »
Great! Last rebase worked fine, AND the current one (on which I decided to tackle one more commit than usual) is going fine, too.
Two rebases left, at most! Once I finish this one...
Two rebases left, at most! Once I finish this one...
2013
The Pub / Re: git rebase is a joke...
« on January 12th, 2014, 01:34 AM »
Copying the ref files manually and updating the hash value for master worked.
In the meantime I did one more rebase and it didn't trigger errors.
I'm currently doing an additional one (each rebase takes something like an hour), and so far so good.
Then I'll have about two rebases left to do. Hopefully I can pinpoint the one fixup that breaks the repo. Maybe nothing will break it. If something breaks it, I'll probably just leave it be. After all, it's only a stat-related rebase (ie I don't want line removal and addition stats to be influenced too much by crlf commits that usually add thousands of lines in the stats.)
Still. Rebasing was so hard, I swear after that, I won't be tempted to do it again! Thankfully, as the repo will then be public, I would be crazy to rebase after that point.
My goal for public repo release is January 15 (and a public alpha a couple of weeks after that at most). Will probably come later if I lose too much time with rebasing.
In the meantime I did one more rebase and it didn't trigger errors.
I'm currently doing an additional one (each rebase takes something like an hour), and so far so good.
Then I'll have about two rebases left to do. Hopefully I can pinpoint the one fixup that breaks the repo. Maybe nothing will break it. If something breaks it, I'll probably just leave it be. After all, it's only a stat-related rebase (ie I don't want line removal and addition stats to be influenced too much by crlf commits that usually add thousands of lines in the stats.)
Still. Rebasing was so hard, I swear after that, I won't be tempted to do it again! Thankfully, as the repo will then be public, I would be crazy to rebase after that point.
My goal for public repo release is January 15 (and a public alpha a couple of weeks after that at most). Will probably come later if I lose too much time with rebasing.
2014
The Pub / git rebase is a joke...
« on January 11th, 2014, 06:18 PM »
Okay, so this git rebase feature is a joke...
IIRC, the Wedge repo was built using svn-git, and then fully converted to git. It's got, due to its SVN background, a fully linear history (except at the end, when I was experiencing with branches.)
Yesterday, I decided to go ahead and do the full rebase I wanted to do, to fix these problems:
- Many CRLF fixes in the first commits, which should be concatenated to their parent commit, so that the CRLF problems fix themselves.
- One more CRLF fix in late 2012. This one's been bothering me for a while, because it adds two useless steps to most Git Blame operations.
- An empty commit (entirely empty, really.)
- An empty commit message (this is a wrong manipulation, but the message exists in the New Revs topic, it's rev 142.)
That was more than enough to justify the rebase.
So, I started off by rebasing the CRLF stuff early in the history. As a result, I kept getting 3-way merge errors, insisting that some files were missing, or other silly things. Given that it's a LINEAR history, and that the only work was done was to cancel CRLF line endings, there's absolutely no reason for these.
Any ideas?
After several hours of failures, I decided to give it up, and instead start fixing from the most recent commits, and then work my way up.
I got rid of the empty commit easily (all it took was git filter-branch --prune-empty), then did a rebase on the 2012 bug, which seems to be fixed. Okay, all good...
Now, onto that empty commit message. What I did was retrieve the SHA1 of the grandfather commit, do git rebase -i on that SHA1, then when the list shows up, change 'pick' to 'reword' in the empty commit message line. Then I save, it shows me a commit window, I paste my rev 142 content, quit, and it starts rebasing. Until the end. ALL GOOD.
Then I right-clicked the Wedge repo, Show Log, and... Funny. You can see the error message below.
It still shows me the master and all commits, but I can't access the branch list, and switch to any of them.
I then restarted from scratch (well, before the last rebase), and I still got the same. That reword rebase totally breaks my refs.
From what I could gather, between my broken Wedge's .git folder and the last valid one, there are a few differences. Broken has an empty refs folder, except for the 'stash' file. All its subfolders are there, but empty. In Working, all subfolders have a list of files corresponding to the expected refs (master, other branches, etc.)
OTOH, Working has an info folder with just an 'exclude' file, while Broken has an extra file in it, called 'refs', and which holds a list of all my branches, like this:
9c63905a2072705aaf93d12866e3f81890f5fc39 refs/heads/master
So, basically, I'm thinking I could just re-create the files manually in /refs/, but (1) it's taxing, (2) I'm never gonna know if I forgot to fix something else, (2) I'll probably have the same problem again when I try another rebase, (3) I don't even know why git (command line) doesn't complain (if I type git status, I get a list of branches), and TortoiseGit is complaining.
Can anyone help..? (ema? :sob:)
IIRC, the Wedge repo was built using svn-git, and then fully converted to git. It's got, due to its SVN background, a fully linear history (except at the end, when I was experiencing with branches.)
Yesterday, I decided to go ahead and do the full rebase I wanted to do, to fix these problems:
- Many CRLF fixes in the first commits, which should be concatenated to their parent commit, so that the CRLF problems fix themselves.
- One more CRLF fix in late 2012. This one's been bothering me for a while, because it adds two useless steps to most Git Blame operations.
- An empty commit (entirely empty, really.)
- An empty commit message (this is a wrong manipulation, but the message exists in the New Revs topic, it's rev 142.)
That was more than enough to justify the rebase.
So, I started off by rebasing the CRLF stuff early in the history. As a result, I kept getting 3-way merge errors, insisting that some files were missing, or other silly things. Given that it's a LINEAR history, and that the only work was done was to cancel CRLF line endings, there's absolutely no reason for these.
Any ideas?
After several hours of failures, I decided to give it up, and instead start fixing from the most recent commits, and then work my way up.
I got rid of the empty commit easily (all it took was git filter-branch --prune-empty), then did a rebase on the 2012 bug, which seems to be fixed. Okay, all good...
Now, onto that empty commit message. What I did was retrieve the SHA1 of the grandfather commit, do git rebase -i on that SHA1, then when the list shows up, change 'pick' to 'reword' in the empty commit message line. Then I save, it shows me a commit window, I paste my rev 142 content, quit, and it starts rebasing. Until the end. ALL GOOD.
Then I right-clicked the Wedge repo, Show Log, and... Funny. You can see the error message below.
It still shows me the master and all commits, but I can't access the branch list, and switch to any of them.
I then restarted from scratch (well, before the last rebase), and I still got the same. That reword rebase totally breaks my refs.
From what I could gather, between my broken Wedge's .git folder and the last valid one, there are a few differences. Broken has an empty refs folder, except for the 'stash' file. All its subfolders are there, but empty. In Working, all subfolders have a list of files corresponding to the expected refs (master, other branches, etc.)
OTOH, Working has an info folder with just an 'exclude' file, while Broken has an extra file in it, called 'refs', and which holds a list of all my branches, like this:
9c63905a2072705aaf93d12866e3f81890f5fc39 refs/heads/master
So, basically, I'm thinking I could just re-create the files manually in /refs/, but (1) it's taxing, (2) I'm never gonna know if I forgot to fix something else, (2) I'll probably have the same problem again when I try another rebase, (3) I don't even know why git (command line) doesn't complain (if I type git status, I get a list of branches), and TortoiseGit is complaining.
Can anyone help..? (ema? :sob:)
2015
The Pub / Re: Wedge translation pt_PT (Git questions)
« on January 10th, 2014, 10:31 PM »I called the folder portuguese-pt exacly for that reason.
I'm trying git in a vps to see if i can learn something about it and im already crazy on how complicated it is to just overwrite a file.
You could simply install Github for Windows, it's not great but it doesn't need any dependencies. Or, install TortoiseGit, I think it comes with msysgit, you just need to leave the default settings at install, and then you should be able to do everything with menu commands.
Basically, you can use git like SVN, only the terminology changes (mostly these two: commit in svn = commit then push in git, update = pull in git), you don't really need to look into the rest, but you'll still have to learn how branching works (basically, when you checkout (switch) to another branch, your repo folder actually refreshes to show the contents of that branch, so you can't switch to another branch if you have uncommitted stuff in your current branch, because git can't keep track of these files later.)
The admin.english.php is already translated but i need to go to school so later ill review it.
I just need to watch the repo language to know if you commit a change to a file right?
You have to right click the folder in TortoiseGit, Settings, Git > Remote, enter 'upstream' (or 'official', or whatever) in the Remote input box, then "https://github.com/Wedge/languages.git" (without quotes) in the URL box, then click on Add New/Save. Click OK.
Now, when you want to get the official updates to the files, you'll have to right-click your folder, TortoiseGit > Pull, then choose upstream/official in the Remote select box, and confirm. Your repo's master branch will be updated with my changes. You can then merge these changes (not rebase them) into your portuguese branch, and then update your Portuguese files accordingly.
In the (likely) case that we get duplicate merges when you do pull requests, I'll either rebase them myself to fix the stuff, or, quite probably, simply ignore them. I like keeping the Wedge history clean, but the languages folder history..? Well, I can't be anal about everything, I suppose.
Anyway, I should probably make a FAQ out of this... Hi Farjo :P
2016
The Pub / Re: Wedge translation pt_PT (Git questions)
« on January 10th, 2014, 06:56 PM »
You can create a new folder in the repo, for instance 'portuguese' or 'portuguese-pt' (I think there are more Brazilians online than Portuguese so it might be worth putting the distinction, just like for English, although I don't really mind either way), copy the English files into it, and start translating them. You can then commit your stuff to your repo (right-click with TortoiseGit on your folder, click TortoiseGit > Commit, and in the commit window, make sure to check 'New branch', name it, then for the next commits you won't have to re-create that branch. Just stay on it for as long as you need.)
Push to your github repo when you want to share (it's okay if some files are only half-translated, but keep untranslated files away from your repo preferably.) Then create a pull request over there.
There are tons of tutorials available. Good luck learning what git is and what it does, because it's hard, even for a seasoned developer like me. Thankfully, as a committer you don't have to know *as many* things about git as I do. If you screw up, I consider it my job to try and ensure it doesn't happen again.
Anyway...! Translating Wedge is a long and annoying task, so I certainly won't put hurdles into your road to completion.
Push to your github repo when you want to share (it's okay if some files are only half-translated, but keep untranslated files away from your repo preferably.) Then create a pull request over there.
There are tons of tutorials available. Good luck learning what git is and what it does, because it's hard, even for a seasoned developer like me. Thankfully, as a committer you don't have to know *as many* things about git as I do. If you screw up, I consider it my job to try and ensure it doesn't happen again.
Anyway...! Translating Wedge is a long and annoying task, so I certainly won't put hurdles into your road to completion.
2017
Features / Re: One theme to rule them all?
« on January 10th, 2014, 04:56 PM »Well given I'm not particularly techie, and I do not understand some of what you say, please go easy on me.
In your current structure (reply 57), where do the media and attachment folders go? Could attachments be a subfolder of media?
Why is there a template folder if templates are no more?
When you talk about a 'core' folder, do you mean the public_html folder or will there be a folder named 'core' with all the other folders off of it? And if so will a site's address be "mysite.tld/core/" ?
It looks mush better to have the languages folder straight off the root, however I don't quite understand the folder's structure.
In the ./languages/ folder there'll be admin.english.php admin.french.php and all the other english and french files, but the other languages' files will be put where?
And then moved somewhere? Will they come with the original product download or will each language pack be on wedge.org as an optional extra?
Scripts: is there any danger of a different scripting language becoming popular?
If not jscript then perhaps something that's not widely heard of - yet. If so should the js folder be named 'scripts' in case someone wants to script in this other as yet unnamed and unknown scripting language and there isn't a natural home for it. As for confusion of putting php files into it, surely people will see what's what when they look and see that the folder only contains js files and php files are elsewhere.
I'm considering renaming it to 'code', so that Sources files show up first in my commit log (I'm absolutely used to that...!), and to avoid confusion with 'skins', but (1) will I get used to that name? (2) will people be confused with a folder called /core/code/..? Does that mean I should rename /core/ to something else? But I like that name...
2018
Development blog / You're talkin' to me?
« on January 10th, 2014, 04:16 PM »
Happy new year, then!
I'm pleased to announce that the Wedge codebase will soon make it to the public. I'm nearly finished with the whole theme removal thing (which took me weeks to fine-tune), and while I'm sure you will find tons of bugs in the public repo (most of which I'm aware of), it *will* be usable, and will become even more usable as others volunteer to help. I still can't give you a date, it could be today, or in a week. But definitely this month.
In the meantime, here's my last present before (hopefully) the Wedge public repo:
https://github.com/Wedge/languages
This is the long-awaited repo for the Wedge language files.
You can technically clone this repo into your /core/ folder (which is what I'll be doing), and then you get the English and French translations without any other manipulations (except flushing the language cache, of course. I really need to do that automatically.)
As explained in the readme, if you're going to start a new translation, create a new folder in a new branch of your local repo, don't forget to sign-off any commits you do (otherwise I won't be able to accept them), and then do pull requests whenever you like.
I'd also recommend that you create a new topic somewhere to announce your plans, so that you don't get into conflicts with other potential translators.
Note: you must be acquainted with the git system if you want to get into this. I won't hold you by the hand, although someone else on the forum might.
I'm pleased to announce that the Wedge codebase will soon make it to the public. I'm nearly finished with the whole theme removal thing (which took me weeks to fine-tune), and while I'm sure you will find tons of bugs in the public repo (most of which I'm aware of), it *will* be usable, and will become even more usable as others volunteer to help. I still can't give you a date, it could be today, or in a week. But definitely this month.
In the meantime, here's my last present before (hopefully) the Wedge public repo:
https://github.com/Wedge/languages
This is the long-awaited repo for the Wedge language files.
You can technically clone this repo into your /core/ folder (which is what I'll be doing), and then you get the English and French translations without any other manipulations (except flushing the language cache, of course. I really need to do that automatically.)
As explained in the readme, if you're going to start a new translation, create a new folder in a new branch of your local repo, don't forget to sign-off any commits you do (otherwise I won't be able to accept them), and then do pull requests whenever you like.
I'd also recommend that you create a new topic somewhere to announce your plans, so that you don't get into conflicts with other potential translators.
Note: you must be acquainted with the git system if you want to get into this. I won't hold you by the hand, although someone else on the forum might.
2019
Features / Re: Plugin revs
« on January 10th, 2014, 02:31 PM »
[master b98600a]
5 files changed, 5 insertions(+), 5 deletions(-), 7.23 KiB (there's something wrong with this repo, I say.)
* Updates for the new file structure, etc... (mentions/plugin.js, SkinSelector.php, WedgeDesk stuff.)
5 files changed, 5 insertions(+), 5 deletions(-), 7.23 KiB (there's something wrong with this repo, I say.)
* Updates for the new file structure, etc... (mentions/plugin.js, SkinSelector.php, WedgeDesk stuff.)
2020
Features / Re: New revs
« on January 10th, 2014, 02:24 PM »
[master d3d6572]
309 files changed, 0 insertions(+), 0 deletions(-)
* Okay... Step 1: rename Themes to core. The rest will follow, I don't want to screw it up.
[master d614364]
187 files changed, 0 insertions(+), 0 deletions(-)
* Step 2: move Sources to core/sources. Phew...
[master e902490]
2 files changed, 0 insertions(+), 0 deletions(-)
* Step 3: move Plugins to core/plugins.
[master 83b218c]
92 files changed, 184 insertions(+), 174 deletions(-), 421.48 KiB (total for all commits in this push.)
* Started updating the program with the new folder structure. I'm totally sweating right now. Moved template files to templates subfolder. Introduced a CORE constant to make it easier to link to these subfolders. (Load.php, QueryString.php, Subs-Cache.php, Subs-Template.php, Themes.php, contributors.txt, install.php, install.sql, ManageBoards.template.php, ManagePlugins.template.php, maybe others.)
* Reverted core/plugins to plugins, to avoid the risk of having core/ URLs in the HTML. I could have ammended my last commit, but this allows me to change the folder to lowercase without any issues with git follow rename. (plugins/*)
* Details. (ManageServer.php, ScheduledTasks.php)
! Fixed SSI link. (Home.template.php)
! Fixed undefined variable in session reading. (Load.php)
- Removed what seems to be a buggy line in the plugin CSS cache code that was supposed to be replaced by a fix, but both lines remained in there. Hmm. QC anyone? (Subs-Cache.php)
- Getting rid of folder names for add_js_file calls to any files within the javascript folder. I'm also considering removing the js extension to match add_css_file calls, but I'm not sure yet. I like adding the js extension, for some reason. (37 files; Admin, Class-Editor, Load, ManageBans, ManageBoards, Profile, Subs-Cache, Subs-Editor, Subs, Aeva-Foxy, Aeva-Gallery2, Aeva-ModCP, Aeva-Subs-Vital, ManageMedia, ManageMedia2; TEMPLATES: Admin, Boards, Display, Login, ManageBoards, ManageMembergroups, ManageNews, ManagePaid, Media, MessageIndex, PersonalMessage, Profile, Recent, Register, Reminder, Stats, index; SKINS: skin.xml, Warm/skin.xml, Wilde/skin.xml, Wine/skin.xml, Wuthering/skin.xml)
NB - This is the quasi-final folder structure, but it may get tweaked depending on my needs, really. At this point, I accept the idea that I'll have an unclean portion of my git history (with many successive folder renames), but it's okay, as it won't hurt either Show Log or Blame in TortoiseGit.
309 files changed, 0 insertions(+), 0 deletions(-)
* Okay... Step 1: rename Themes to core. The rest will follow, I don't want to screw it up.
[master d614364]
187 files changed, 0 insertions(+), 0 deletions(-)
* Step 2: move Sources to core/sources. Phew...
[master e902490]
2 files changed, 0 insertions(+), 0 deletions(-)
* Step 3: move Plugins to core/plugins.
[master 83b218c]
92 files changed, 184 insertions(+), 174 deletions(-), 421.48 KiB (total for all commits in this push.)
* Started updating the program with the new folder structure. I'm totally sweating right now. Moved template files to templates subfolder. Introduced a CORE constant to make it easier to link to these subfolders. (Load.php, QueryString.php, Subs-Cache.php, Subs-Template.php, Themes.php, contributors.txt, install.php, install.sql, ManageBoards.template.php, ManagePlugins.template.php, maybe others.)
* Reverted core/plugins to plugins, to avoid the risk of having core/ URLs in the HTML. I could have ammended my last commit, but this allows me to change the folder to lowercase without any issues with git follow rename. (plugins/*)
* Details. (ManageServer.php, ScheduledTasks.php)
! Fixed SSI link. (Home.template.php)
! Fixed undefined variable in session reading. (Load.php)
- Removed what seems to be a buggy line in the plugin CSS cache code that was supposed to be replaced by a fix, but both lines remained in there. Hmm. QC anyone? (Subs-Cache.php)
- Getting rid of folder names for add_js_file calls to any files within the javascript folder. I'm also considering removing the js extension to match add_css_file calls, but I'm not sure yet. I like adding the js extension, for some reason. (37 files; Admin, Class-Editor, Load, ManageBans, ManageBoards, Profile, Subs-Cache, Subs-Editor, Subs, Aeva-Foxy, Aeva-Gallery2, Aeva-ModCP, Aeva-Subs-Vital, ManageMedia, ManageMedia2; TEMPLATES: Admin, Boards, Display, Login, ManageBoards, ManageMembergroups, ManageNews, ManagePaid, Media, MessageIndex, PersonalMessage, Profile, Recent, Register, Reminder, Stats, index; SKINS: skin.xml, Warm/skin.xml, Wilde/skin.xml, Wine/skin.xml, Wuthering/skin.xml)
NB - This is the quasi-final folder structure, but it may get tweaked depending on my needs, really. At this point, I accept the idea that I'll have an unclean portion of my git history (with many successive folder renames), but it's okay, as it won't hurt either Show Log or Blame in TortoiseGit.
2021
Test board / Re: First Test in 2014
« on January 10th, 2014, 12:28 AM »
Well, there's a footnote in your first post, and clicking the [1] leads to nothing at all. It isn't parsed by Wedge. Dunno why. :-/
2022
Features / Re: One theme to rule them all?
« on January 9th, 2014, 11:08 PM »
Well, I guess the 'way to do it' would be to use CSS anyway.
background: url($here/myimage.png), or sum'ing like that. I don't do plugins (which is a bit of a problem since I'm the only Wedge developer by now), and Dragooon and live are MIA these days (especially Dragooon), so it's gonna take someone else to spot usability issues for plugin authors, and fix them, or point them out to me.
In the meantime, it's probably meaningless to bother about that.
I'm more annoyed with the fact that, on my local install, I'm having trouble finding my marks with the new folder structure -- not really the fact that they're all in a subfolder now, but more the fact that Sources is now lowercased, and it makes it harder for me to find it immediately. I didn't expect that I was relying SO MUCH on ucfirst'ed names to find folders quickly.
Ah, well... I guess it'll just take some time to get used to, or something.
Also, the fact that templates are currently in the root of /core/ is a bit strange, but I don't know what I can put into that folder anyway. I'm really, really bothered by the idea of having sources in the core folder, because I don't want any clutter as subfolders, I only want the 'solid' ones like javascript, languages, etc.
Finally, I'm also bothered that my skins folder is located before my sources folder. Plus, they look similar in name, so I tend to click on sources to get CSS files, or skins to get PHP files. Renaming skins to something else..? I figured 'themes' would make sense, but... That means it gets awfully similar to the 'templates' folder (which doesn't exist for now, cf. the fact that templates are in the root for now.)
It's interesting, how hard it is to find a new folder structure that 'works'... :^^;:
:edit: Aaaaaand, 14.000 posts! That deserves a few elaborate answers from a few of you, I'm sure... Hopefully I'll have some feedback when I wake up tomorrow! As Koreans would say: Fightin'!! (I don't know why they say that, really... But it's in every single modern K-drama.)
background: url($here/myimage.png), or sum'ing like that. I don't do plugins (which is a bit of a problem since I'm the only Wedge developer by now), and Dragooon and live are MIA these days (especially Dragooon), so it's gonna take someone else to spot usability issues for plugin authors, and fix them, or point them out to me.
In the meantime, it's probably meaningless to bother about that.
I'm more annoyed with the fact that, on my local install, I'm having trouble finding my marks with the new folder structure -- not really the fact that they're all in a subfolder now, but more the fact that Sources is now lowercased, and it makes it harder for me to find it immediately. I didn't expect that I was relying SO MUCH on ucfirst'ed names to find folders quickly.
Ah, well... I guess it'll just take some time to get used to, or something.
Also, the fact that templates are currently in the root of /core/ is a bit strange, but I don't know what I can put into that folder anyway. I'm really, really bothered by the idea of having sources in the core folder, because I don't want any clutter as subfolders, I only want the 'solid' ones like javascript, languages, etc.
Finally, I'm also bothered that my skins folder is located before my sources folder. Plus, they look similar in name, so I tend to click on sources to get CSS files, or skins to get PHP files. Renaming skins to something else..? I figured 'themes' would make sense, but... That means it gets awfully similar to the 'templates' folder (which doesn't exist for now, cf. the fact that templates are in the root for now.)
It's interesting, how hard it is to find a new folder structure that 'works'... :^^;:
:edit: Aaaaaand, 14.000 posts! That deserves a few elaborate answers from a few of you, I'm sure... Hopefully I'll have some feedback when I wake up tomorrow! As Koreans would say: Fightin'!! (I don't know why they say that, really... But it's in every single modern K-drama.)
2023
Features / Re: One theme to rule them all?
« on January 9th, 2014, 08:25 PM »
A problem I met while doing this... The plugins folder was put in the root for at least one good reason: plugins can access images directly from within their folders, so if you show an icon, it'll use <img src="mysite/Plugins/myplugin/myimage.png">, so moving plugins to core/plugins will make the URL longer. Ouch... I'd like to avoid these links in HTML as much as possible. Opinions..?
2024
Features / Re: One theme to rule them all?
« on January 9th, 2014, 06:48 PM »
I'm getting plenty of likes on my latest thought, but no actually feedback, so I guess I'll have to choose by myself...
My current structure is thus:
Code: [Select]
I thought 'core' made sense as the root folder. 'javascript' is a conscious choice to make it clearer that 'scripts' are 'JavaScript', not 'PHP scripts'.
languages will have French and English US at its root, and German and English UK in sub-folders, to match the future official languages repo. You'll probably need to move the folder contents to the languages folder though, if you want to have them enabled. Not sure yet.
Plugins are part of the rest, because that makes it easier to update them, and they're most likely to be uploaded by FTP, so I'm *hoping* we won't be getting problems with file permissions. (At worst, I could simply create that folder at runtime, so that Wedge can be sure it can manipulate its contents without filesystem problems.)
skins are the CSS folders, sources is the original Sources folder (meaning core is technically empty, which I'm not too happy with, but the alternative would be to have /core/media and /core/notifiers and /core/captcha in addition to the files above, and I'm not sure I want that), and templates are /Themes/default.
Everyone happy with this..?
My current structure is thus:
/core
/javascript
/languages
/plugins
/skins
/sources
/templatesI thought 'core' made sense as the root folder. 'javascript' is a conscious choice to make it clearer that 'scripts' are 'JavaScript', not 'PHP scripts'.
languages will have French and English US at its root, and German and English UK in sub-folders, to match the future official languages repo. You'll probably need to move the folder contents to the languages folder though, if you want to have them enabled. Not sure yet.
Plugins are part of the rest, because that makes it easier to update them, and they're most likely to be uploaded by FTP, so I'm *hoping* we won't be getting problems with file permissions. (At worst, I could simply create that folder at runtime, so that Wedge can be sure it can manipulate its contents without filesystem problems.)
skins are the CSS folders, sources is the original Sources folder (meaning core is technically empty, which I'm not too happy with, but the alternative would be to have /core/media and /core/notifiers and /core/captcha in addition to the files above, and I'm not sure I want that), and templates are /Themes/default.
Everyone happy with this..?
2025
Features / Re: One theme to rule them all?
« on January 8th, 2014, 11:51 PM »
Site is updated with the latest revision. It was broken for about 10 minutes (completely for a minute or two; partially for the rest.) If you find any problems, please report them. I also tested the session-based cache, and I'm getting slightly better results, just like on my local install, but so far, my page load record for shortest time is held by the file-based cache (.06s on New Revs page 1), followed by session-based cache (.07s at best). I only tested about a dozen page refreshes per cache type, so your mileage may vary. Also, session-based seems to be more consistent, so I'll probably eventually use it.
...
Still waiting on more feedback for the folder structure..?
...
Still waiting on more feedback for the folder structure..?