2021-10-30, 04:43 AM
@Devilshakerz,
Please pardon the delay - I've been low on energy and then catching up on tasks that built up during my low-energy period. Also, for some reason I've found it difficult to parse your ideas. I don't know why, because you write clearly, but it means that I've had to spend a lot of time trying to understand and then develop a response.
I understand you to be saying that in the absence of a
If so, that's what I meant when I wrote that if we can always rely on the
Also, re placeholder directories: can you give me an example of when a placeholder directory would ever be used/useful given the possibility of using a
I think you might be suggesting here that automatically keeping
Can you elaborate on the nature of this new directory,
That's something I hadn't considered when suggesting this "redundant" approach: during development, the "archived" version of
I think that we could avoid problems like that by adopting the "Upload zipped plugins/themes via the ACP, or upload them unzipped to a 'staging' directory and then visit the ACP" approach that I suggested earlier. I am not sure whether you have objections to that approach, and, if so, what they are, but it seems to me to be the least problematic approach during both development and production.
Again, if we ensured via the approach I reraised above that the
Similarly to my immediately previous comment: the approach I've suggested seems to avert the need for code like this in that the
Do you see any problems with this approach?
Wait, when would a manifest file ever declare an "unknown" version? Surely that would be/invoke an error?
Again, this problem does not occur on the approach I've suggested.
On the approach I've suggested, when a developer released a new version, s/he would simply make a copy on his/her development machine of the newly released
A temporary override of whatever the latest versioned directory is?
That all sounds very error-prone, especially watching content for changes.
Please pardon the delay - I've been low on energy and then catching up on tasks that built up during my low-energy period. Also, for some reason I've found it difficult to parse your ideas. I don't know why, because you write clearly, but it means that I've had to spend a lot of time trying to understand and then develop a response.
(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]We can be more lenient and accept packages with both placeholders and stamped versions, so that if developers:the resulting packages could still work: the system would only need to look for leftover placeholder names and rename/"archive" them before use. If version numbers were already applied, it would do nothing.
- copy files from a live forum, where directories are already stamped
- make a package from a repository where a placeholder is used, without making any changes
This assumes no inherent need forcurrent/directories for production use.
I understand you to be saying that in the absence of a
current/ directory, the system selects in its place the directory with the most recent version (and this seems to be affirmed by that which you write in parentheses below). Yes?If so, that's what I meant when I wrote that if we can always rely on the
current/ directory being present, then we avoid the need for various checks/determinations: in that case, we don't have to perform (even if inexpensive) checks to determine which versioned directory is most recent; we just always use current/.Also, re placeholder directories: can you give me an example of when a placeholder directory would ever be used/useful given the possibility of using a
current/ directory instead? Why do/would we need both, or, at least, why is/would it be useful to support both ("current" as well as placeholder directories)?(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ](2021-10-25, 07:41 PM)Devilshakerz Wrote: [ -> ]Quote:Would thecurrent/or the "archived" directory be used by the system for fetching Resources and including files?
Thecurrent/directory. It's the simplest and most direct approach, avoiding the need for various checks/determinations.
It may lead to - potentially unexpected - implementation difficulties when specific versions have to resolve to "live" directories (and if the deviation described above also applies to this approach, the system would need to accept the latest version directory in the absence ofcurrent/).
I think you might be suggesting here that automatically keeping
current/ and its archived version in sync is prone to errors, or am I misunderstanding?(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]Generally, with the described redundancy, all data that may be needed during production use could be resolved using standardized paths/"archives" (with stamped versions, wherelatest/is considered equivalent to a specificv*/directory).
Can you elaborate on the nature of this new directory,
latest/? What would its contents be, how does it fit in, and why is it useful/necessary?(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]When developing extensions, though, only thecurrent/content would be modified - so e.g. when a parent theme's Resource is edited there, and its "archived" version becomes stale, it would only propagate down when queries for the parent's Resources are properly resolved toinc/themes/[parent]/current.
That's something I hadn't considered when suggesting this "redundant" approach: during development, the "archived" version of
current/ would go stale when changes were made to current/. That seems to me to be a serious problem.I think that we could avoid problems like that by adopting the "Upload zipped plugins/themes via the ACP, or upload them unzipped to a 'staging' directory and then visit the ACP" approach that I suggested earlier. I am not sure whether you have objections to that approach, and, if so, what they are, but it seems to me to be the least problematic approach during both development and production.
(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]This could be simple enough (e.g. thecurrent/directory would have priority in arrays of template directories for Twig), but unless the system is well-aware of the filesystem state (i.e. maintains an accurate cache of which extensions have acurrent/directory, and which versions they override), it may be necessary to additionally read manifest files to make sure the override directories are intended for the queried versions to avoid unintended behavior.
Resources and metadata for any version of any extension may be queried at any time (especially when the system is expected to track and analyze extension interactions - vertical [inheritance] and horizontal [themes-plugins]), so this resolution would need be involved always, and globally.
Again, if we ensured via the approach I reraised above that the
current/ directory is always available and - well, current - then no awareness nor caching is necessary. It seems to me to be the simplest approach.(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]An example resolution function could look like this:
(the 3 conditions may also be "hidden" in afunction getThemePackageStylesheetsPath(string $name, string $version): string { if ( // `current/` doesn't apply to old "archives" $version === getThemePackageLatestVersion(themeName: $name) && // `current/` may not exist (if our approach allows that) themePackageHasCurrentDirectory(themeName: $name) && // `current/` may declare a version different than the one queried $version === getThemePackageVersionFromManifest(themeName: $name, versionDirectory: 'current') ) { $liveVersionDirectory = 'current'; } else { $liveVersionDirectory = 'v' . $version; } return THEMES_DIRECTORY . '/' . $name . '/' . $liveVersionDirectory . '/stylesheets'; }current/-awaregetThemePackageLatestVersion()function)
Similarly to my immediately previous comment: the approach I've suggested seems to avert the need for code like this in that the
current/ directory would never be duplicated via an archived version directory - that corresponding version directory would only be created under controlled circumstances in which its contents are being replaced by the upload of a new current directory with a new version in its manifest file.Do you see any problems with this approach?
(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]Some side effects could appear during development - current/ directories with a manifest file declaring an unknown version would be "archived", but further changes would not be copied.Wait, when would a manifest file ever declare an "unknown" version? Surely that would be/invoke an error?
(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]The unnecessary "archives" would first be ignored by the system (since thecurrent/directories are expected to override them), but may be confusing when looking at the contents ofinc/themes/[name](so some developers may copy the automatically created directory - indicating a version they just authored - that may be stale, instead ofcurrent/).
Again, this problem does not occur on the approach I've suggested.
(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]Additionally, when further version bumps are made, such potentially invalid "archives" may then be actually used as sources of information for previous versions on the development installation.
On the approach I've suggested, when a developer released a new version, s/he would simply make a copy on his/her development machine of the newly released
current/ directory to its versioned directory, and then update the version number in the manifest file for the current/ directory as suitable for the next planned release.(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]Alternatively to such permanent routing, we can consider:
current/as a temporary override
Content incurrent/directories would override the version directory specified in the manifest (and prevent the system from renamingcurrent/, if that's being done).
This would still require checking for potential override directories when attempting to fetch data from "archives", but the behavior would be limited to a "development mode".
A temporary override of whatever the latest versioned directory is?
(2021-10-26, 01:53 PM)Devilshakerz Wrote: [ -> ]
current/as source
Detectcurrent/changes and copy them to the relevant version directory (compatible with the redundancy approach).
In this case, a more accurate name for thecurrent/directories would besource/ororigin/:
- the system watches its content for changes, which are copied to version directories indicated by versions in manifest files (we can add some protection against overwriting anything else than the latest version directory for each extension)
- they're read-only for the whole application
- they're never "live" (other than the mirroring operation, no component is allowed to use/include/read its content)
This could take thecurrent/-related routing out of consideration for the extension system, and all data could be fetched from locations with standardized paths, without additional conditions or exceptions.
It may be acceptable to require less restrictive filesystem permissions for development, and contents of a stamped directory could still be modified instead.
This may also necessitate adding/extending a "development mode" to reduce performance impact of the additional filesystem activity.
That all sounds very error-prone, especially watching content for changes.